DNSOP Working Group H. Dong Internet-Draft A. Kaizer Intended status: Standards Track J. Harvey Expires: 30 April 2027 B. Kaliski S. Sheth Verisign Labs 27 October 2026 Module-Lattice-Based Signatures with Merkle Tree Ladders (ML-DSA-MTL) for DNSSEC with SigTag Extension draft-hdong-dnsop-ml-dsa-mtl-dnssec-sigtag-ext-01 Abstract This document describes a mechanism to reduce post-quantum cryptographic (PQC) network transmission overhead when using Merkle Tree Ladders (MTL) in DNS Security Extensions (DNSSEC). This document refers to this as SigTag and describes the use of EDNS(0) to enable its use. SigTag allows a client to indicate its knowledge of a specific MTL ladder. The DNS server can then use this signal to determine if it can omit the full underlying signature in its response, thereby reducing the message payload. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 30 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Dong, et al. Expires 30 April 2027 [Page 1] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG October 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. SigTag . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. MTL-Type Value in RRSIG Resource Record . . . . . . . . . 5 4. The SigTag EDNS(0) Option . . . . . . . . . . . . . . . . . . 5 4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 5 5. Use of SigTag by Clients . . . . . . . . . . . . . . . . . . 6 5.1. Client Handling of SigTag in Queries . . . . . . . . . . 6 5.1.1. With No Knowledge of SigTags . . . . . . . . . . . . 6 5.1.2. With Known SigTag(s) . . . . . . . . . . . . . . . . 6 5.2. Summary of Expected Client Queries . . . . . . . . . . . 7 5.3. Selection of SigTag . . . . . . . . . . . . . . . . . . . 7 5.4. Client Handling of SigTag in Responses . . . . . . . . . 7 6. Use of SigTag by Servers . . . . . . . . . . . . . . . . . . 7 6.1. Server Handling of SigTag in Queries . . . . . . . . . . 8 6.2. Server Handling of SigTag in Responses . . . . . . . . . 8 6.2.1. Summary of Expected Server Responses Per RRSIG . . . 9 6.2.2. Deduplication Optimization . . . . . . . . . . . . . 9 7. Operational and Security Considerations . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Dong, et al. Expires 30 April 2027 [Page 2] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG October 2026 1. Introduction Merkle Tree Ladder (MTL) is a technique for using an underlying signature scheme to authenticate an evolving series of messages. The application of the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) [FIPS204] and MTL as a conservative post-quantum cryptographic (PQC) algorithm for DNS Security Extensions (DNSSEC) is detailed in [I-D.kaizer-dnsop-ml-dsa-mtl-dnssec]. As specified in [I-D.kaizer-dnsop-ml-dsa-mtl-dnssec], a DNSSEC RRSIG for MTL contains both a condensed signature (authentication path/ Merkle tree inclusion proof) unique to an RRset and a signed ladder that contains a PQC signature. The signed ladder can potentially be used to authenticate multiple condensed signatures. A signed ladder is included in every RRSIG in [I-D.kaizer-dnsop-ml-dsa-mtl-dnssec]. This can provide computational and storage efficiency through ladder reuse but does not reduce network transmission overhead. When a client already knows the ladder required for verification, the server does not need to retransmit it; the server can transmit only the condensed signatures, hence reducing network transmission overhead. This document specifically defines an EDNS(0) option that allows a client to signal its capability to use this mechanism, referred to hereafter as SigTag, or to indicate its knowledge of a specific SigTag. 1.1. Definitions This document uses the terminology from [I-D.kaizer-dnsop-ml-dsa-mtl-dnssec] as a baseline. Additional terms applicable to the concepts in this draft are provided here in alphabetical order: SigTag An identifier that refers to a specific signed MTL ladder. 1.2. Assumptions To make SigTag as presently defined workable, we generally need three things: 1. The node set is append-only (which implies leaves are added consecutively, never modified, or removed from the node set once included) 2. The server can uniquely determine the number of rungs and their index pairs in the ladder based on SID, N, and other information available to the server 3. The ladder associated with SID and N covers the first N leaves in the tree associated with SID Dong, et al. Expires 30 April 2027 [Page 3] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG October 2026 The binary rung strategy described in Section 1.3 of [I-D.kaizer-dnsop-ml-dsa-mtl-dnssec] meets these assumptions. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The single pipe character, "|", is used to denote concatenation as is done in [RFC4034]. All RRSIG elements and EDNS(0) fields specified in this document are unsigned integers in network byte order (big endian order). 3. SigTag SigTag uniquely identifies a specific signed ladder within a signer's scope. In this document, SigTag is defined in a way that a DNS client can construct a SigTag from a received or cached signed ladders. This document defines the SigTag value for an MTL signature as the concatenation of the series identifier (SID) and the right index of the signed ladder: SigTag = (SID | right_index) 0 8 16 +-----------------------------------------------+ | | // SID // | (32-octets) | +-----------------------------------------------+ | | | Right Index | | (8-octets) | | | +-----------------------------------------------+ Where: * SID, a 32-octet series identifier of the node set, as defined in Section 5.1.1 of [I-D.kaizer-dnsop-ml-dsa-mtl-dnssec] * Right Index, an 8-octet value denoting the rightmost index of the signed ladder Dong, et al. Expires 30 April 2027 [Page 4] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG October 2026 3.1. MTL-Type Value in RRSIG Resource Record As defined in Section 4 of [I-D.kaizer-dnsop-ml-dsa-mtl-dnssec], the signature field of the RRSIG RR begins with a one-octet MTL-Type, followed by the MTL Authentication Data: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTL-Type | | +-+-+-+-+-+-+-+-+ | | MTL Authentication Data | / / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This document adds a new MTL-Type value to the MTL-Types registry maintained by IANA: * The MTL-Type MUST be set to condensed (0x02) for condensed signatures. 4. The SigTag EDNS(0) Option A SigTag-aware DNS client may signal its support for, or knowledge of a specific SigTag by including the SigTag EDNS(0) option in its query as described in [RFC6891]. 4.1. Option Format The SigTag EDNS(0) option is encoded as follows: 0 8 16 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | OPTION-CODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | OPTION-LENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | // OPTION-DATA // | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Where: OPTION-CODE The 2-octet EDNS(0) option code assigned to the MTL SigTag, TBD. OPTION-LENGTH A 2-octet field containing the length of the OPTION- Dong, et al. Expires 30 April 2027 [Page 5] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG October 2026 DATA field. OPTION-DATA Zero or more SigTag values. The OPTION-CODE assigned to this version of SigTag is specific to this version. Future formats of SigTag will require a dedicated OPTION-CODE. 5. Use of SigTag by Clients A SigTag-aware client MAY include the SigTag EDNS(0) option in its query. 5.1. Client Handling of SigTag in Queries 5.1.1. With No Knowledge of SigTags If a SigTag-aware client has no knowledge of any SigTags, it SHOULD signal its support for SigTag by leaving the EDNS(0) OPTION-DATA field empty and set the OPTION-LENGTH field to 0. This enables the client to determine whether the server supports SigTag (Section 6). The SigTag format is illustrated as follows: 0 8 16 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | OPTION-CODE = TBD | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | OPTION-LENGTH = 0x0000 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 5.1.2. With Known SigTag(s) The client SHOULD include any SigTag values it believes are relevant to the current query in the OPTION-DATA field and set the OPTION- LENGTH field to the length of the OPTION-DATA field to signal its knowledge of one or more specific ladders to the server: 0 8 16 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | OPTION-CODE = TBD | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | OPTION-LENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | | // OPTION-DATA = SigTag(s) // | (40-octets per SigTag) | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Dong, et al. Expires 30 April 2027 [Page 6] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG October 2026 Each 40-octet per-SigTag value is obtained by concatenating the SID and the right index of the signed ladder, as specified in Section 3. 5.2. Summary of Expected Client Queries +================+=============+=======================+ | Support SigTag | Know SigTag | Query | +================+=============+=======================+ | N | - | - | +----------------+-------------+-----------------------+ | Y | N | SigTag EDNS(0) with | | | | empty OPTION-DATA | +----------------+-------------+-----------------------+ | Y | Y | SigTag EDNS(0) with | | | | SigTag in OPTION-DATA | +----------------+-------------+-----------------------+ Table 1: Expected DNS Client Behavior 5.3. Selection of SigTag A DNS message MAY include multiple different SigTags under conditions such as multiple signers, key rollovers, or scenarios where the client maintains multiple cached ladders. When multiple SigTags are included in the OPT meta-RR, they MUST be concatenated into a single OPTION-DATA field. This document limits the maximum number of SigTags in one DNS query to 8 SigTags to bound the potential overhead of this approach. It is RECOMMENDED that a SigTag-aware DNS client advertise SigTags by prioritizing the highest right index to minimize subsequent queries and increase the likelihood that the client retains relevant signed ladders for a given period. 5.4. Client Handling of SigTag in Responses The client SHOULD determine that the server supports SigTag by verifying that the response does not return an RCODE of FORMERR, as specified in [RFC6891]. If the server supports SigTag, the client MUST ignore any data present within the OPTION-DATA field of the server's SigTag EDNS(0) option. 6. Use of SigTag by Servers Dong, et al. Expires 30 April 2027 [Page 7] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG October 2026 6.1. Server Handling of SigTag in Queries If the client includes the SigTag EDNS(0) option, the server MUST also include the SigTag EDNS(0) option in the response to signal its support for SigTag. The server MUST set the EDNS(0) OPTION-LENGTH to 0 and leave the OPTION-DATA field empty in its response, as the client will construct its SigTag values from received or cached ladders. If a received query does not contain the SigTag EDNS(0) option, the server MUST NOT include the SigTag EDNS(0) option in its response, in accordance with [RFC6891]. If a received query includes the SigTag EDNS(0) option and the OPTION-LENGTH does not match the internal boundaries of the payload, or if the option payload contains more than 8 instances of SigTag, the server MUST treat the query as malformed and return a response with the RCODE set to FORMERR as specified in [RFC6891]. 6.2. Server Handling of SigTag in Responses For each MTL RRSIG in the response, the server SHOULD process as follows: * If no matching SigTag is advertised: the server MUST return a full signature as described in Section 5.1 of [I-D.kaizer-dnsop-ml-dsa-mtl-dnssec]. * If a valid, matching SigTag is advertised: the server SHOULD return a condensed signature as defined in Section 5.1.1 of [I-D.kaizer-dnsop-ml-dsa-mtl-dnssec], where the condensed signature can be verified relative to the signed ladder associated with the SigTag value. The associated MTL-Type MUST be set to condensed (0x02) as specified in Section 3.1. where matching is defined as can the RRSIG be verified relative to the signed ladder identified by the SigTag. If the server is unable to construct a condensed signature that can be verified relative to the signed ladder referenced by the client- provided SigTag, the server MUST return a full signature. The binary rung strategy has the "backward compatibility" property that a condensed signature based on the current signed ladder can be verified relative to any previous signed ladder that covers the relevant leaf. If the binary rung strategy is employed, the current condensed signature can therefore be returned when the leaf index is less than N. Dong, et al. Expires 30 April 2027 [Page 8] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG October 2026 6.2.1. Summary of Expected Server Responses Per RRSIG +=========================+=================+===========+ | Request Supports SigTag | Request Has A | Respond | | | Matching SigTag | | +=========================+=================+===========+ | N | - | Full Sig | +-------------------------+-----------------+-----------+ | Y | N | Full Sig | +-------------------------+-----------------+-----------+ | Y | Y | Condensed | | | | Sig | +-------------------------+-----------------+-----------+ Table 2: Expected DNS Server Behavior Per RRSIG 6.2.2. Deduplication Optimization When a client signals its support for SigTag, the server SHOULD treat this as an indication that the following deduplication optimization is supported. Future drafts may define other deduplication strategies, such as providing nodes shared by two or more authentication paths only once. For this version, the server SHOULD perform a deduplication optimization when all of the following conditions are met: * Multiple RRSIG records in the response can be verified relative to the same signed ladder, and * The signed ladder does not match any SigTag advertised by the client. To perform this optimization, the server SHOULD deduplicate its response by including each common signed ladder within a full signature only once. When deduplication is performed, the full signature MUST be present in the first RRSIG that requires it. Other RRSIG records within the response that can be verified by the same signed ladder as in the full signature SHALL be condensed signatures. 7. Operational and Security Considerations Clients should be aware that using SigTag may expose knowledge of specific ladders which could, e.g., reveal information about previous queries a client has made or allow a client to be tracked by an authoritative who provides unique SigTag values to every client. Clients concerned about this MAY transmit only an empty SigTag every time to achieve the de-duplication benefits without revealing known SigTags or engage in strategies such as flushing their SigTag related cache when changing IP addresses or interfaces to limit tracking by Dong, et al. Expires 30 April 2027 [Page 9] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG October 2026 such properties. Clients concerned about query retries MAY perform their SigTag- enabled queries directly over TCP. These clients will still benefit from the bandwidth savings provided by including SigTags in their TCP-based DNS requests, provided that the server has a condensed signature that can be verified using the ladder identified by the SigTag. Clients caching signed ladders MUST store them in association with their respective signers. If a SigTag-enabled client receives a server response that cannot be validated, the client MAY retry using one of the following fallback strategies: * Resend the request including the SigTag EDNS(0) option with an empty OPTION-DATA field. * Resend the request without the SigTag EDNS(0) option and expect to receive full signatures. * Direct the request with the SigTag EDNS(0) option to a different DNS server. Examples of such invalid responses include, but are not limited to, mismatched condensed signatures or missing payloads. 8. IANA Considerations This document requests IANA to add a new entry to the DNSSEC MTL Type Parameters Registry requested by [I-D.kaizer-dnsop-ml-dsa-mtl-dnssec], as follows: +=======+=====================+==========+=================+ | Value | Description | Mnemonic | Reference | +=======+=====================+==========+=================+ | 0x02 | Condensed Signature | COND_SIG | [this document] | +-------+---------------------+----------+-----------------+ Table 3: DNSSEC MTL Type Parameters Registry Entry 9. Implementation Status NOTE: Please remove this section and the reference to RFC 7942 prior to publication as an RFC. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 7942. Dong, et al. Expires 30 April 2027 [Page 10] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG October 2026 The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". For testing purposes, SigTag has been implemented in the following DNS open-source applications: * LDNS for key generation, zone signing, and zone verification with MTL: https://github.com/Verisign/mtl-mode-ldns * NSD authoritative name server with MTL: https://github.com/verisign/mtl-mode-nsd * Unbound recursive resolver with MTL: https://github.com/Verisign/ mtl-mode-unbound These implementations depend on the reference implementation of MTL which is available in C. The MTL library can be found at https://github.com/Verisign/MTL. 10. Acknowledgements This I-D has drawn from helpful examples of document structure and specification text from various DNSSEC algorithm RFCs. The authors express their gratitude to the authors of those RFCs for their contributions. Special thanks are also extended to Daniel McVicker for his valuable suggestions and contributions. 11. References 11.1. Normative References [FIPS204] National Institute of Standards and Technology (NIST), "Module-Lattice-Based Digital Signature Standard", FIPS PUB 204, DOI 10.6028/NIST.FIPS.204, 13 August 2024, . Dong, et al. Expires 30 April 2027 [Page 11] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG October 2026 [I-D.kaizer-dnsop-ml-dsa-mtl-dnssec] Kaizer, A., Harvey, J., Kaliski, B., and S. Sheth, "Module-Lattice-Based Signatures with Merkle Tree Ladders (ML-DSA-MTL) for DNSSEC", Work in Progress, Internet- Draft, draft-kaizer-dnsop-ml-dsa-mtl-dnssec-00, 6 July 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . Appendix A. Change Log 00: Initial draft of the document. 01: Added assumptions for SigTag, updated the deduplication optimization to account for other strategies in future drafts, and requested an IANA allocation for a new MTL Type. Authors' Addresses H. Dong Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States of America Email: hdong@verisign.com URI: https://www.verisignlabs.com/ Dong, et al. Expires 30 April 2027 [Page 12] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG October 2026 A. Kaizer Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States of America Email: akaizer@verisign.com URI: https://www.verisignlabs.com/ J. Harvey Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States of America Email: jsharvey@verisign.com URI: https://www.verisignlabs.com/ B. Kaliski Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States of America Email: bkaliski@verisign.com URI: https://www.verisignlabs.com/ S. Sheth Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States of America Email: ssheth@verisign.com URI: https://www.verisignlabs.com/ Dong, et al. Expires 30 April 2027 [Page 13]