Revised IANA Considerations for DNSSECICANNpaul.hoffman@icann.orgThis document changes the review requirements needed to get DNSSEC algorithms
and resource records added to IANA registries.
It updates RFC 6014 to include hash algorithms for Delegation Signer (DS) records
and NextSECure version 3 (NSEC3) parameters (for Hashed Authenticated Denial of Existence). It also updates RFCs 5155 and 6014, which have requirements for DNSSEC
algorithms, and updates RFC 8624 to clarify the implementation recommendation related to the algorithms described in RFCs that are not on the standards track.
The rationale for these changes is to bring the requirements for DS records
and hash algorithms used in NSEC3 in line with the requirements for
all other DNSSEC algorithms.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Requirements Language
. Update to RFC 6014
. Update to RFC 8624
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgements
Author's Address
IntroductionDNSSEC is primarily described in , , and .
DNSSEC commonly uses another resource record beyond those defined in :
NSEC3 .
DS resource records were originally defined in , and that definition
was obsoleted by . updates the requirements for how DNSSEC cryptographic algorithm
identifiers in the IANA registries are assigned, reducing the requirements
from "Standards Action" to "RFC Required".
However, the IANA registry requirements for hash algorithms for DS records
and for the hash algorithms used in NSEC3 records are still "Standards Action".
This document updates those IANA registry requirements.
(For a reference on how IANA registries can be updated in general, see .)Requirements Language
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.
Update to RFC 6014 updates to bring the requirements for DS records
and NSEC3 hash algorithms in line with the rest of the DNSSEC cryptographic algorithms
by allowing any DS hash algorithms, NSEC3 hash algorithms,
NSEC3 parameters, and NSEC3 flags that are fully described in an RFC
to have identifiers assigned in the IANA registries.
This is an addition to the IANA considerations in .Update to RFC 8624This document updates for all DNSKEY and DS algorithms that are not
on the standards track.The second paragraph of currently says:
This document only provides recommendations with respect to
mandatory-to-implement algorithms or algorithms so weak that they
cannot be recommended. Any algorithm listed in the [DNSKEY-IANA]
and [DS-IANA] registries that are not mentioned in this document
MAY be implemented. For clarification and consistency, an
algorithm will be specified as MAY in this document only when it
has been downgraded from a MUST or a RECOMMENDED to a MAY.
That paragraph is now replaced with the following:
This document provides recommendations with respect to
mandatory-to-implement algorithms, algorithms so weak that they
cannot be recommended, and algorithms defined in RFCs
that are not on the standards track. Any algorithm listed in the
[DNSKEY-IANA] and [DS-IANA] registries that are not mentioned in
this document MAY be implemented. For clarification and
consistency, an algorithm will be specified as MAY in this document only when it has been downgraded from a MUST or a
RECOMMENDED to a MAY.
This update is also reflected in the IANA considerations in .IANA ConsiderationsIn the "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) Parameters"
registry, the registration procedure for "DNSSEC NSEC3 Flags", "DNSSEC NSEC3
Hash Algorithms", and "DNSSEC NSEC3PARAM Flags" has been changed from "Standards
Action" to "RFC Required", and this document has been added as a reference.In the "DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" registry, the registration procedure for "Digest Algorithms" has been changed from "Standards Action" to "RFC Required", and this document has been added as a reference.Security ConsiderationsChanging the requirements for adding security algorithms to IANA
registries as described in this document will make it easier to add both good
and bad algorithms to the registries.
It is impossible to weigh the security impact of those two changes.Administrators of DNSSEC-signed zones and validating resolvers may have been making
security decisions based on the contents of the IANA registries.
This was a bad idea in the past, and now it is an even worse idea because there will be more
algorithms in those registries that may not have gone through IETF review.
Security decisions about which algorithms are safe and not safe should be made by
reading the security literature, not by looking in IANA registries.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn 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.DNS Security Introduction and RequirementsThe 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]Resource Records for the DNS Security ExtensionsThis 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]Protocol Modifications for the DNS Security ExtensionsThis 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]DNS Security (DNSSEC) Hashed Authenticated Denial of ExistenceThe Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK]Cryptographic Algorithm Identifier Allocation for DNSSECThis document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated. It changes the requirement from "standard required" to "RFC Required". It does not change the list of algorithms that are recommended or required for DNSSEC implementations. [STANDARDS-TRACK]Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 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.Algorithm Implementation Requirements and Usage Guidance for DNSSECThe DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of nonexistence. To ensure interoperability between DNS resolvers and DNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletes RFC 6944.Informative ReferencesDelegation Signer (DS) Resource Record (RR)The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference. This document defines the DS RR, gives examples of how it is used and describes the implications on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC 1035, RFC 2535, RFC 3008 and RFC 3090.Acknowledgements, , , , and
contributed to this document.Author's AddressICANNpaul.hoffman@icann.org