Verisign Labs

12061 Bluemont Way Reston 20190 USA VA hdong@verisign.com https://www.verisignlabs.com/

Verisign Labs

12061 Bluemont Way Reston 20190 USA VA akaizer@verisign.com https://www.verisignlabs.com/

Verisign Labs

12061 Bluemont Way Reston 20190 USA VA jsharvey@verisign.com https://www.verisignlabs.com/

Verisign Labs

12061 Bluemont Way Reston 20190 USA VA bkaliski@verisign.com https://www.verisignlabs.com/

Verisign Labs

12061 Bluemont Way Reston 20190 USA VA ssheth@verisign.com https://www.verisignlabs.com/

Internet DNSOP Working Group Signature DNSSEC Algorithm 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.

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) and MTL as a conservative post-quantum cryptographic (PQC) algorithm for DNS Security Extensions (DNSSEC) is detailed in . As specified in , 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 . 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.

Definitions This document uses the terminology from 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.

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 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 . All RRSIG elements and EDNS(0) fields specified in this document are unsigned integers in network byte order (big endian order).

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: SigTag = SHAKE128(SIGNED_LADDER, 256) 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 , including the signature size and the signature fields:

MTL-Type Value in RRSIG Resource Record As defined in Section 4 of , the signature field of the RRSIG RR begins with a one-octet MTL-Type, followed by the 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.

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 .

Option Format The SigTag EDNS(0) option is encoded as follows: 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.

Use of SigTag by Clients A SigTag-aware client MAY include the SigTag EDNS(0) option in its query.

Client Handling of SigTag in Queries

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 ). The SigTag format is illustrated as follows:

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: The 32-octet per SigTag value is obtained by hashing the respective signed ladder, as specified in .

Summary of Expected Client Queries Expected DNS Client Behavior

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

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.

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 . If the server supports SigTag, the client MUST ignore any data present within the OPTION-DATA field of the SigTag EDNS(0) option.

Use of SigTag by Servers

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 . 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 .

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 .
• If a valid, matching SigTag is advertised: the server SHOULD return a condensed signature as defined in Section 5.1.1 of , 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 .

If the server no longer possesses the signed ladder referenced by the client-provided SigTag, the server MUST return a full signature.

Summary of Expected Server Responses Per RRSIG Expected DNS Server Behavior Per RRSIG

Request Supports SigTag	Request Has A Matching SigTag	Respond
N	-	Full Sig
Y	N	Full Sig
Y	Y	Condensed Sig

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.

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. 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.

IANA Considerations

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:
• NSD authoritative name server with MTL:
• Unbound recursive resolver with MTL:

These implementations depend on the reference implementation of MTL which is available in C. The MTL library can be found at .

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.

References Normative References National Institute of Standards and Technology (NIST) Verisign Labs Verisign Labs Verisign Labs Verisign Labs Informative References

Change Log

• 00: Initial draft of the document.