]> Cloudflare

bas@cloudflare.com

Google

sschmieg@google.com

Security Domain Name System Operations DNSSEC ML-DSA post-quantum FIPS 204 signatures This document describes how to specify Module-Lattice-Based Digital Signature Algorithm (ML-DSA) keys and signatures in DNS Security (DNSSEC). It uses the ML-DSA-44 parameter set defined in FIPS 204. ML-DSA-44 is believed to be secure even against adversaries in possession of a cryptographically relevant quantum computer. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Domain Name System Operations Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction DNSSEC, which is broadly defined in , , and , uses cryptographic keys and digital signatures to provide authentication of DNS data. Currently the most popular signature algorithms in use are RSA and the NIST-specified elliptic curve signature algorithm ECDSA . All currently specified algorithms rely for their security on the hardness of the integer factorization problem or the (elliptic curve) discrete logarithm problem. A cryptographically relevant quantum computer when built would be able to solve both of these problems efficiently, and would therefore be able to forge DNSSEC signatures created with any of these algorithms. specifies the Module-Lattice-Based Digital Signature Algorithm (ML-DSA), a signature scheme whose security is based on the hardness of lattice problems over module lattices. ML-DSA is believed to be secure even against adversaries in possession of a cryptographically relevant quantum computer. defines three parameter sets: ML-DSA-44, ML-DSA-65, and ML-DSA-87. This document defines the use of DNSSEC's DS, DNSKEY, and RRSIG resource records (RRs) with the ML-DSA-44 parameter set. ML-DSA-44 targets NIST security category 2, which equates to 160 bits of security classical and post-quantum security. ML-DSA-44 has the smallest keys and signatures of the three ML-DSA parameter sets, which makes it the most suitable for use in the DNS.

Conventions and Definitions 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.

DNSKEY Resource Records An ML-DSA-44 public key consists of a 1312-octet value as produced by the key generation algorithm ML-DSA.KeyGen defined in Section 5.1 of . It is encoded into the Public Key field of a DNSKEY resource record as a simple bit string, using the byte encoding of the public key described in Section 7.2 of .

RRSIG Resource Records An ML-DSA-44 signature consists of a 2420-octet value as produced by the signing algorithm ML-DSA.Sign defined in Section 5.2 of . It is encoded into the Signature field of an RRSIG resource record as a simple bit string, using the byte encoding of the signature described in Section 7.2 of . Signatures are generated and verified using the "pure" ML-DSA variant (i.e., not the pre-hash variant HashML-DSA) with an empty context string (ctx of zero length), as described in Sections 5.2 and 5.3 of . The message signed is the data to be signed as described in Section 3.1.8.1 of .

Algorithm Number for DS, DNSKEY, and RRSIG Resource Records The algorithm number associated with the use of ML-DSA-44 in DS, DNSKEY, and RRSIG resource records is 18 (please). This registration is fully defined in the IANA Considerations section.

Examples The following example, in the style of Section 6 of , shows an ML-DSA-44 DNSKEY, its corresponding DS record, and an RRSIG over an MX RRset. The key was generated deterministically from the 32-octet seed shown in the PrivateKey field, and the signature was produced using the deterministic variant of ML-DSA (rnd set to all zeroes) so that the example is byte-for-byte reproducible. Because of the size of ML-DSA-44 keys and signatures, the base64-encoded values are wrapped.

Security Considerations

ML-DSA The security considerations of apply. In particular sections 3.4 and 3.6 of discuss additional considerations for implementing ML-DSA, including guidance on the choice of hedged vs deterministic variants. These considerations apply when ML-DSA is used for DNSSEC and especially during online signing.

Downgrades Section 5.11 of recommends validators to accept any single valid path. Such lenient validators are vulnerable to a downgrade attack: if a zone is signed by ML-DSA-44 and a quantum-vulnerable algorithm, then a quantum attacker can strip the ML-DSA-44 signatures, and have the lenient validator accept the forged quantum-vulnerable signature. This does not apply if the validator does not accept any quantum-vulnerable algorithms or if the zone is only signed by ML-DSA-44.

IANA Considerations This document updates the IANA registry "Domain Name System Security (DNSSEC) Algorithm Numbers". The following entry is to be added to the registry: New DNSSEC Algorithm Number entry

Field	Value
Number	18 (please)
Description	ML-DSA-44
Mnemonic	MLDSA44
Zone Signing	Y
Trans. Sec.	*
Use for DNSSEC Signing	MAY
Use for DNSSEC Validation	MAY
Implement for DNSSEC Signing	MAY
Implement for DNSSEC Validation	MAY
Reference	(this document)

* There has been no determination of standardization of the use of this algorithm with Transaction Security.

References Normative References The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] National Institute of Standards and Technology (NIST) In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes how to specify Elliptic Curve Digital Signature Algorithm (DSA) keys and signatures in DNS Security (DNSSEC). It lists curves of different sizes and uses the SHA-2 family of hashes for signatures. [STANDARDS-TRACK] This document is a collection of technical clarifications to the DNS Security (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing. This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of the DNSSEC specification.

Acknowledgments TODO