]> Cloudflare

jabley@cloudflare.com

Operations and Management Domain Name System Operations dnssec local policy algorithm PQC Security-aware resolvers validate signatures, where available, in order to protect their clients from inauthentic data. DNSSEC treats all algorithms as equal when it comes to validation, such that a single valid signature is considered sufficient proof of authenticity, and that data is only to be judged to be inauthentic if all available signatures are found to be invalid. However, a resolver might have a different local policy, e.g. in its handling of quantum-safe signatures. This document discusses such local policy and describes a means to indicate to a client that specific local policy has been applied to response validation. 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 DNS Security Extensions (DNSSEC) are specified in . DNSSEC provides a mechanism to attach cryptographic signatures to a subject RRSet. Signatures are encoded in a DNS message alongside the subject RRSet as an RRSIG RRSet with the same owner name, TTL and class. Different RRSIG RRs in such an RRSet might correspond to different signing keys and different signing algorithms. In the process for determining the authenticity of an RRSet with more than one associated signature (RRSIG) is considered. The specification defers the matter of whether every RRSIG needs to be checked individually to local policy:

• If other RRSIG RRs also cover this RRset, the local resolver security policy determines whether the resolver also has to test these RRSIG RRs and how to resolve conflicts if these RRSIG RRs lead to differing results.

This guidance is further clarified in as follows:

• This document specifies that a resolver SHOULD accept any valid RRSIG as sufficient, and only determine that an RRset is Bogus if all RRSIGs fail validation. If a resolver adopts a more restrictive policy, there's a danger that properly signed data might unnecessarily fail validation due to cache timing issues. Furthermore, certain zone management techniques, like the Double Signature Zone Signing Key Rollover method described in , will not work reliably. Such a resolver is also vulnerable to malicious insertion of gibberish signatures.

This document describes one such "more restrictive policy" relating to the introduction of quantum-safe algorithms in DNSSEC, and describes a signal that can be used to inform a relying party that such a policy is in place.

Conventions and Definitions This document uses DNS terminology as described in . This document applies the phrase "quantum-safe" to cryptographic algorithms and signatures made by those algorithms in the loose sense of offering acceptable protection against cryptanalyic attack by a quantum computer. This usage is consistent with general, contemporary discussion of so-called post-quantum cryptography. This document uses the phrase "quantum-unsafe" to mean something that is not quantum-safe.

Deployment of Quantum-Safe Algorithms in DNSSEC Certain cryptographic algorithms have been identified as being to weak to withstand cryptanalytic attack by a quantum computer. Examples of such algorithms used in DNSSEC are ECDSA Curve P-256 with SHA-256 and RSA/SHA-256 . In this document we refer to such algorithms as quantum-unsafe. However, there exist other algorithms that are considered quantum-safe, such as Module-Lattice-Based Digital Signature Standard {?FIPS204} whose use in DNSSEC as ML-DSA-44 is described in . Quantum-safe algorithms are not widely-deployed in DNSSEC at the time of writing, and there is no known prediction of their rapid deployment. DNSSEC validators are required to ignore signatures made using algorithms that they do not support. To publish data in the DNS with broad integrity protection for relying parties that includes the use of quantum-safe algorithms, it is therefore necessary to include multiple signatures over the subject data: signatures with widely-deployed, quantum-unsafe algorithms for the legacy population of validators and also signatures with poorly-deployed, quantum-safe algorithms intended for validators that support them. Signing with quantum-safe algorithms alone would afford no integrity protection at all to the legacy validator population. The classsification of algorithms as quantum-safe or quantum-unsafe imagines a future in which the ability to validate a signature made by a quantum-unsafe algorithm no longer provides sufficient confidence that the signed data is authentic. However, a signature over the same data by a quantum-safe algorithm would provide that confidence, to a validator that is equipped to use it. Such a validator might therefore implement a local policy to ignore signatures made using quantum-unsafe algorithms when signatures made by quantum-safe algorithms are also available for the same subject data. Such a policy would treat data with a valid quantum-safe signature as authentic regardless of the validity of any other signature, and treat data with an invalid quantum-safe signature as inauthentic even if valid signatures made by quantum-unsafe algorithms are available. The operator of a security-aware resolver that adopted this local policy would naturally pay close attention to the concerns expressed in .

Signals to Clients of Resolvers The local policy described in would have the effect of suppressing some positive DNS responses that might otherwise have been returned to a client: in particular, when validation of a quantum-unsafe signature over some RRSet succeded while validation of a quantum-safe signature over the same RRSet did not. To the end-user, this is indinguishable from DNS response filtering and existing mechanisms described in can be used to provide supporting information. A negative DNS response that follows a failure to validate according to the local policy described in might include an Extended DNS Error Code 6 ("DNSSEC Bogus") and include indirect references to the specific policy in force encoded in the EXTRA-TEXT field. For example:

Security Considerations This document provides an example of local policy relating to DNSSEC validation that could be employed by the operator of a security-aware resolver to address weaknesses in quantum-unsafe signing algorithms. Local policy is often no friend of interoperability. In this case the parties affected by local policy decisions might well have made an informed decision to use a resolver with known local policy, in which case resulting differences in validation behaviour will presumably be well-aligned with the relying parties. However, particular resolvers are also commonly assigned to devices without an informed decision-making process with an end user, in which case differences in behaviour might be surprising. The Extended DNS Error described in } provides a mechanism for a resolver operator to communicate the existence of local policy to a client such that the reason for the different behaviour can be better understood.

IANA Considerations This document has no IANA actions.

References Normative References This document describes the DNS Security Extensions (commonly called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC. This document does not update any of those RFCs. A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice. A third purpose is to provide a single reference for other documents that want to refer to DNSSEC. 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] 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. This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 4641, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. Cloudflare Google [I-D.ietf-dnsop-structured-dns-error] introduces structured error data for DNS responses that have been filtered. This specification allows more specific details of filtering incidents to be conveyed. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mnot/public-resolver-errors. This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. Informative References National Institute of Standards and Technology (NIST) 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 describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (RFC 4033, RFC 4034, and RFC 4035). [STANDARDS TRACK] Cloudflare Google 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.

Acknowledgments Your name here, etc.