DNSOP Working Group H. Dong Internet-Draft A. Kaizer Intended status: Standards Track J. Harvey Expires: 1 April 2027 B. Kaliski S. Sheth Verisign Labs 28 September 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-00 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 1 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Dong, et al. Expires 1 April 2027 [Page 1] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG September 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. SigTag . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. MTL-Type Value in RRSIG Resource Record . . . . . . . . . 4 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 the 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 . . . 8 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 . . . . . . . . . . . . . . . . . 11 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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]. Dong, et al. Expires 1 April 2027 [Page 2] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG September 2026 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. 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 for an MTL signature as the hash of the signed ladder: Dong, et al. Expires 1 April 2027 [Page 3] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG September 2026 SigTag = SHAKE128(SIGNED_LADDER, 256) 0 8 16 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | // SigTag = Signed Ladder Hash // | (32-octets) | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ The input to the hash function MUST be the serialization of the components of the Signed Ladder (shown in the figure below) as defined in Section 5.1.2 of [I-D.kaizer-dnsop-ml-dsa-mtl-dnssec], including the signature size and the signature fields: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-------------------------------+ | Flags (2-octets) | +-------------------------------+ | | // SID // | (32-octets) | +-------------------------------+ | Rung Count (2-octets) | +-------------------------------+ | | // Rung Data // | (32-octets per rung) | +-------------------------------+ | Underlying Signature Length | | (4-octets) | +-------------------------------+ | | // Underlying Signature // | (2420-octets) | +-------------------------------+ 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: Dong, et al. Expires 1 April 2027 [Page 4] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG September 2026 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- DATA field. OPTION-DATA Zero or more SigTag values. Dong, et al. Expires 1 April 2027 [Page 5] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG September 2026 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 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) // | (32-octets per SigTag) | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ The 32-octet per SigTag value is obtained by hashing the respective signed ladder, as specified in Section 3. Dong, et al. Expires 1 April 2027 [Page 6] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG September 2026 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 the 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 that are most relevant in the client's preferred order to minimize subsequent queries and ensure that the client retains valid 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 SigTag EDNS(0) option. 6. Use of SigTag by Servers Dong, et al. Expires 1 April 2027 [Page 7] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG September 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. If the server no longer possesses the signed ladder referenced by the client-provided SigTag, the server MUST return a full signature. 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 | Dong, et al. Expires 1 April 2027 [Page 8] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG September 2026 | | | 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. The server SHOULD perform a deduplication optimization when all of the following conditions are met: * Multiple RRSIG records in the response have condensed signatures that can be verified using 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 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. Dong, et al. Expires 1 April 2027 [Page 9] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG September 2026 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 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. 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 Dong, et al. Expires 1 April 2027 [Page 10] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG September 2026 * 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, . [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, . Dong, et al. Expires 1 April 2027 [Page 11] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG September 2026 [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. 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/ 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/ Dong, et al. Expires 1 April 2027 [Page 12] Internet-Draft ML-DSA-MTL-DNSSEC-SIGTAG September 2026 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 1 April 2027 [Page 13]