1. Introduction
"DNS Security Extensions (DNSSEC)" [RFC9364] is used to provide authentication of DNS data. The DNSSEC signing algorithms are defined by various RFCs, including [RFC4034], [RFC4509], [RFC5155], [RFC5702], [RFC5933], [RFC6605], and [RFC8080].
To ensure interoperability, a set of "mandatory-to-implement" DNS Public Key (DNSKEY) algorithms are defined in [RFC8624]. To make the current status of the algorithms more easily accessible and understandable, and to make future changes to these recommendations easier to publish, this document moves the canonical status of the algorithms from [RFC8624] to the IANA DNSSEC algorithm registries. This document also incorporates the revised IANA DNSSEC considerations from [RFC9157]. Additionally, as advice to operators, it adds recommendations for deploying and using these algorithms.
This is similar to the process used for the "TLS Cipher Suites" registry [TLS-ciphersuites], where the canonical list of cipher suites is in the IANA registry, and RFCs reference the IANA registry.
1.1. Document Audience
The columns added to the IANA "DNS Security Algorithm Numbers" [DNSKEY-IANA] and "Digest Algorithms" [DS-IANA] registries target DNSSEC operators and implementers.
Implementations need to meet high security expectations as well as provide interoperability between various implementations and with different versions.
The field of cryptography evolves continuously. New, stronger algorithms appear, and existing algorithms may be found to be less secure than originally thought. Therefore, algorithm implementation requirements and usage guidance need to be updated from time to time in order to reflect the new reality and to allow for a smooth transition to more secure algorithms as well as the deprecation of algorithms deemed to no longer be secure.
Implementations need to be conservative in the selection of algorithms they implement in order to minimize both code complexity and the attack surface.
The perspective of implementers may differ from that of an operator who wishes to deploy and configure DNSSEC with only the safest algorithm. As such, this document also adds new recommendations about which algorithms should be deployed regardless of implementation status. In general, it is expected that deployment of aging algorithms should generally be reduced before implementations stop supporting them.
1.2. Updating Algorithm Requirement Levels
By the time a DNSSEC cryptographic algorithm is made mandatory to implement, it should already be available in most implementations. This document defines an IANA registration modification to allow future documents to specify the implementation recommendations for each algorithm, as the recommendation status of each DNSSEC cryptographic algorithm is expected to change over time. For example, there is no guarantee that newly introduced algorithms will become mandatory to implement in the future. Likewise, published algorithms are continuously subjected to cryptographic attack and may become too weak, or even be completely broken, and will require deprecation in the future.
It is expected that the deprecation of an algorithm will be performed gradually. This provides time for implementations to update their implemented algorithms while remaining interoperable. Unless there are strong security reasons, an algorithm is expected to be downgraded from MUST to NOT RECOMMENDED or MAY, instead of directly from MUST to MUST NOT. Similarly, an algorithm that has not been mentioned as mandatory to implement is expected to be first introduced as RECOMMENDED instead of a MUST.
Since the effect of using an unknown DNSKEY algorithm is that the zone is treated as insecure, it is recommended that algorithms that have been downgraded to NOT RECOMMENDED or lower not be used by authoritative nameservers and DNSSEC signers to create new DNSKEYs. This ensures that the use of deprecated algorithms decreases over time. Once an algorithm has reached a sufficiently low level of deployment, it can be marked as MUST NOT, so that recursive resolvers can remove support for validating it.
Validating recursive resolvers are encouraged to retain support for all algorithms not marked as MUST NOT.
1.3. Requirements Notation
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.
[RFC2119] considers the term SHOULD to be equivalent to RECOMMENDED, and SHOULD NOT equivalent to NOT RECOMMENDED. This document has chosen to use the terms RECOMMENDED and NOT RECOMMENDED, as this more clearly expresses the recommendations to implementers.