| Internet-Draft | ML-DSA-MTL-DNSSEC-SIGTAG | September 2026 |
| Dong, et al. | Expires 1 April 2027 | [Page] |
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.¶
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 (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
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.¶
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:¶
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).¶
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:¶
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) |
+-------------------------------+
¶
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:¶
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].¶
The SigTag EDNS(0) option is encoded as follows:¶
0 8 16 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | OPTION-CODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | OPTION-LENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | // OPTION-DATA // | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+¶
Where:¶
A SigTag-aware client MAY include the SigTag EDNS(0) option in its query.¶
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 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+¶
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.¶
| 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 |
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.¶
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.¶
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].¶
For each MTL RRSIG in the response, the server SHOULD process as follows:¶
If the server no longer possesses the signed ladder referenced by the client-provided SigTag, the server MUST return a full signature.¶
| Request Supports SigTag | Request Has A Matching SigTag | Respond |
|---|---|---|
| N | - | Full Sig |
| Y | N | Full Sig |
| Y | Y | Condensed Sig |
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:¶
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.¶
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.¶
If a SigTag-enabled client receives a server response that cannot be validated, the client MAY retry using one of the following fallback strategies:¶
Examples of such invalid responses include, but are not limited to, mismatched condensed signatures or missing payloads.¶
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:¶
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.¶
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.¶