Stateless Hash-Based Signatures in Merkle Tree Ladder Mode (SLH-DSA-MTL) for DNSSEC

The Domain Name System Security Extensions (DNSSEC), which are broadly defined in , and , use cryptographic keys and digital signatures to provide data origin authentication and data integrity in the DNS. This document describes the application of Merkle Tree Ladder (MTL) Mode to the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) as the SLH-DSA-MTL signature scheme for DNSSEC. SLH-DSA is described in the FIPS 205 draft standard and MTL mode is described in . As described herein, a DNSKEY resource record (RR) for an SLH-DSA-MTL key contains a SLH-DSA key. The SLH-DSA key is used for verifying signatures on Merkle tree ladders (MTLs). An RRSIG resource record for an SLH-DSA-MTL Signature contains a Merkle proof (authentication path) that is verifiable using a MTL, and optionally also contains the signed MTL. The anticipation of quantum computers that can break the current signature algorithms led to NIST selecting post-quantum cryptographic (PQC) algorithms for standardization and developing specifications for the algorithms as NIST standards. These new algorithms are expected to replace classical digital signature algorithms (e.g., RSA and ECDSA) in IETF standards and to be widely implemented and deployed after that. NIST's proposed PQC algorithms have significantly larger signature sizes than RSA and ECDSA. The larger sizes may have a significant operational impact on DNSSEC. For example, the size of signed NSEC and NSEC3 responses may exceed UDP MTUs with this degrading the use of UDP as the prevalent DNSSEC transport. Larger signature sizes could also substantially increase memory requirements for in-memory zone databases used by authoritative name servers and for in-memory caches used by resolvers. As described in , MTL mode is designed to reduce the size impact of PQC signature algorithms. For DNSSEC, the size impact reduction is achieved when signatures provided in RRSIG RRs are primarily comprised of "condensed signatures" (Merkle proofs / authentication paths) and are only occasionally comprised of "full signatures" that contain both a condensed signature and a signed MTL, where the signed ladder includes a signature using the underlying PQC signature algorithm. MTL mode reduces the memory requirements for PQC signatures as the signature data in the zone database or cache is primarily comprised of Merkle proofs and only occasionally of signed MTLs . SLH-DSA is a stateless hash-based PQC signature scheme selected by NIST for standardization in July 2022. This document specifies SLH-DSA for the initial application of MTL mode to DNSSEC based on three considerations: (1) SLH-DSA is also based on Merkle trees, and thus already has internal functions for computing leaf nodes and internal nodes; and (2) SLH-DSA has relatively large signature sizes and computational costs, and therefore can benefit significantly from the reductions offered by MTL mode; and (3) hash-based techniques are well understood and offer a conservative choice for long-term security relative to newer NIST selected signature schemes based on lattice-based cryptography. SLH-DSA is based on SPHINCS+ , one of the submissions to NIST's PQC evaluation project, and the algorithms are substantially the same. describes the combination of MTL mode with SPHINCS+. The authors intend to update both and this I-D as needed to be consistent with FIPS 205 once it is published as a NIST FIPS standard. This initial version of the draft focuses on the code-points applicable to DNSKEY and RRSIG formulation and a proposed DNSSEC protocol change to support retrieval of MTL mode condensed signatures and MTL mode full signatures as described in 3., 9.4., and 9.5. of . Later versions may describe DNSSEC protocol and/or operational changes related to zone signing, zone composition, zone updates, zone transfer, name server processing, resolver signature processing, and resolver caching.

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. Double pipe characters, "||" are used in this document to indicate concatenation of the elements preceding and following the double pipe characters. All numeric DNSKEY elements and RRSIG elements specified in this document are unsigned integers in network byte order (big endian order).

An SLHDSAMTLSHA2128S key consists of a 32-octet value, which is encoded into the Public Key field of a DNSKEY resource record as a simple bit string. SLHDSAMTLSHA2128S keys are generated as SLH-DSA keys using the SLH-DSA-SHA2-128s parameter set, as defined in 9.1 and 10 of . An SLHDSAMTLSHAKE128S key consists of a 32-octet value, which is encoded into the Public Key field of a DNSKEY resource record as a simple bit string. SLHDSAMTLSHAKE128S keys are generated as SLH-DSA keys using the SLH-DSA-SHAKE-128s parameter set, as defined in 9.1 and 10 of .

MTL mode signatures are either full or condensed as described in . SLHDSAMTLSHA2128S and SLHDSAMTLSHAKE128S signatures utilize a one-octet prefixed MTL-Type field to indicate whether the signature is condensed (0) or full (1). An SLHDSAMTLSHA2128S signature consists of a variable-length value, which is encoded into the Signature field of an RRSIG resource record as a simple bit string as the concatenation of the MTL-Type and a SLH-DSA-MTL-SHA2-128s signature as described in : An SLHDSAMTLSHAKE128S signature consists of a variable-length value, which is encoded into the Signature field of an RRSIG resource record as a simple bit string as the concatenation of the MTL-Type and a SLH-DSA-MTL-SHAKE-128s signature as described in : The signature and verification algorithms for both SLH-DSA-MTL-SHA2-128s and SLH-DSA-MTL-SHAKE-128s are described in 9.1. and 9.2. of . The signature and verification algorithms for the underlying signature algorithms used for signed ladders elements of SLH-DSA-MTL-SHA2-128s and SLH-DSA-MTL-SHAKE-128s full signatures, SLH-DSA-SHA2-128s and SLH-DSA-SHAKE-128s respectively, are described in 9.2 and 9.3 of .

The algorithm number associated with the use of SLHDSAMTLSHA2128S in DS, DNSKEY, and RRSIG resource records is TBD. The algorithm number associated with the use of SLHDSAMTLSHAKE128S in DS, DNSKEY, and RRSIG resource records is TBD. This registration is fully defined in the IANA Considerations section.

MTL mode signatures are either full or condensed. An MTL mode-aware client MAY request that signatures be returned in the full format by providing the mtl-mode-full EDNS(0) option in the OPT meta-RR of its query .

The mtl-mode-full option is encoded as follows:

where:

OPTION-CODE: The EDNS0 option code assigned to mtl-mode-full, TBD.
OPTION-LENGTH: Always zero.

When a query includes the mtl-mode-full option, the response requirement depends on the number of RRSIG records in the response that were produced in MTL mode:

If exactly one RRSIG record in the response was produced in MTL mode, then that RRSIG record MUST be returned in the full signature format.
If more than one RRSIG record in the response was produced in MTL mode, then enough of these RRSIG records MUST be returned in the full signature format to ensure that every other RRSIG in the response that was produced in MTL mode can be verified.

When the mtl-mode-full option is not included, every signature in the response that was produced in MTL mode MUST be returned in the condensed signature format. As described in 9.2. of , when a verifier receives a condensed signature, the verifier determines whether any of the MTLs it has previously verified includes a rung that is compatible with the authentication path in the condensed signature. If not, then the verifier requests a new signed ladder. Accordingly, a resolver SHOULD first query a name server without the mtl-mode-full option, and then, if needed, re-issue the query with the mtl-mode-full option. Since responses to queries with the mtl-mode-full option are expected to be large, it is RECOMMENDED that queries with the mtl-mode-full option be issued over transports (e.g., TCP, TLS, QUIC) that support large responses without truncation and/or fragmentation.

TBD

This document updates the IANA registry for DNSSEC "Domain Name System Security (DNSSEC) Algorithm Numbers" located at https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml. The following entries are requested to be added to the registry subject to the Number update: * There has been no determination of standardization of the use of these algorithms with Transaction Security.

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". Implementation details are TBD.

The security considerations of and are inherited in the usage of SLH-DSA-MTL in DNSSEC. SLH-DSA-MTL-SHA2-128s and SLH-DSA-MTL-SHAKE-128s are intended to operate at around the 128-bit security level against classical attacks and the 64-bit level against quantum attacks, consistent with NIST's security level I. A private key used for a DNSSEC zone MUST NOT be used for any other purpose than for that zone. Otherwise, cross-protocol or cross-application attacks are possible.

The authors would like to acknowledge the following individuals for their contributions to the development of this document: Scott Hollenbeck, Swapneel Sheth. 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.