rfc9157.original   rfc9157.txt 
Network Working Group P. Hoffman Internet Engineering Task Force (IETF) P. Hoffman
Internet-Draft ICANN Request for Comments: 9157 ICANN
Updates: 5155, 6014, 8624 (if approved) 7 October 2021 Updates: 5155, 6014, 8624 November 2021
Intended status: Standards Track Category: Standards Track
Expires: 10 April 2022 ISSN: 2070-1721
Revised IANA Considerations for DNSSEC Revised IANA Considerations for DNSSEC
draft-ietf-dnsop-dnssec-iana-cons-05
Abstract Abstract
This document changes the review requirements needed to get DNSSEC This document changes the review requirements needed to get DNSSEC
algorithms and resource records added to IANA registries. It updates algorithms and resource records added to IANA registries. It updates
RFC 6014 to include hash algorithms for DS (Delegation Signer) RFC 6014 to include hash algorithms for Delegation Signer (DS)
records and NSEC3 (Hashed Authenticated Denial of Existence) records and NextSECure version 3 (NSEC3) parameters (for Hashed
parameters. It also updates RFC 5155 and RFC 6014, which have Authenticated Denial of Existence). It also updates RFCs 5155 and
requirements for DNSSEC algorithms, and updates RFC 8624 to say that 6014, which have requirements for DNSSEC algorithms, and updates RFC
algorithms that are described in RFCs that are not on standards track 8624 to clarify the implementation recommendation related to the
are only at the "MAY" level of implementation recommendation. The algorithms described in RFCs that are not on the standards track.
rationale for these changes is to bring the requirements for DS The rationale for these changes is to bring the requirements for DS
records and for the hash algorithms used in NSEC3 in line with the records and hash algorithms used in NSEC3 in line with the
requirements for all other DNSSEC algorithms. requirements for all other DNSSEC algorithms.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 10 April 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9157.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Simplified BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Update to RFC 6014 . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
3. Update to RFC 8624 . . . . . . . . . . . . . . . . . . . . . 3 2. Update to RFC 6014
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 3. Update to RFC 8624
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations
6.1. Normative References . . . . . . . . . . . . . . . . . . 4 6. References
6.2. Informative References . . . . . . . . . . . . . . . . . 5 6.1. Normative References
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 6.2. Informative References
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 Acknowledgements
Author's Address
1. Introduction 1. Introduction
DNSSEC is primarily described in [RFC4033], [RFC4034], and [RFC4035]. DNSSEC is primarily described in [RFC4033], [RFC4034], and [RFC4035].
DNSSEC commonly uses another resource record beyond those defined in DNSSEC commonly uses another resource record beyond those defined in
RFC 4034: NSEC3 [RFC5155]. DS resrouce records were originally [RFC4034]: NSEC3 [RFC5155]. DS resource records were originally
defined in [RFC3658], and that definition was obsoleted by RFC 4034. defined in [RFC3658], and that definition was obsoleted by [RFC4034].
[RFC6014] updated the requirements for how DNSSEC cryptographic [RFC6014] updates the requirements for how DNSSEC cryptographic
algorithm identifiers in the IANA registries are assigned, reducing algorithm identifiers in the IANA registries are assigned, reducing
the requirements from being "Standards Action" to "RFC Required". the requirements from "Standards Action" to "RFC Required". However,
However, the IANA registry requirements for hash algorithms for DS the IANA registry requirements for hash algorithms for DS records
records [RFC3658] and for the hash algorithms used in NSEC3 records [RFC3658] and for the hash algorithms used in NSEC3 records [RFC5155]
[RFC5155] are still "Standards Action". This document updates those are still "Standards Action". This document updates those IANA
IANA registry requirements. (For reference on how IANA registries registry requirements. (For a reference on how IANA registries can
can be updated in general, see [RFC8126].) be updated in general, see [RFC8126].)
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Update to RFC 6014 2. Update to RFC 6014
Section 4 updates RFC 6014 to bring the requirements for DS records Section 4 updates [RFC6014] to bring the requirements for DS records
and NSEC3 hash algorithms in line with the rest of the DNSSEC and NSEC3 hash algorithms in line with the rest of the DNSSEC
cryptographic algorithms by allowing any DS hash algorithms, NSEC3 cryptographic algorithms by allowing any DS hash algorithms, NSEC3
hash algorithms, NSEC3 parameters, and NSEC3 flags that are fully hash algorithms, NSEC3 parameters, and NSEC3 flags that are fully
described in an RFC to have identifiers assigned in the IANA described in an RFC to have identifiers assigned in the IANA
registries. This is an addition to the IANA considerations in RFC registries. This is an addition to the IANA considerations in
6014. [RFC6014].
3. Update to RFC 8624 3. Update to RFC 8624
This document updates [RFC8624] for all DNSKEY and DS algorithms that This document updates [RFC8624] for all DNSKEY and DS algorithms that
are not on standards track. are not on the standards track.
The second paragraph of Section 1.2 of RFC 8624 currently says: The second paragraph of Section 1.2 of [RFC8624] currently says:
This document only provides recommendations with respect to | This document only provides recommendations with respect to
mandatory-to-implement algorithms or algorithms so weak that they | mandatory-to-implement algorithms or algorithms so weak that they
cannot be recommended. Any algorithm listed in the [DNSKEY-IANA] | cannot be recommended. Any algorithm listed in the [DNSKEY-IANA]
and [DS-IANA] registries that are not mentioned in this document | and [DS-IANA] registries that are not mentioned in this document
MAY be implemented. For clarification and consistency, an | MAY be implemented. For clarification and consistency, an
algorithm will be specified as MAY in this document only when it | algorithm will be specified as MAY in this document only when it
has been downgraded from a MUST or a RECOMMENDED to a MAY. | has been downgraded from a MUST or a RECOMMENDED to a MAY.
That paragraph is now replaced with the following: That paragraph is now replaced with the following:
This document provides recommendations with respect to | This document provides recommendations with respect to mandatory-
mandatory-to-implement algorithms, algorithms so weak that they | to-implement algorithms, algorithms so weak that they cannot be
cannot be recommended, and algorithms that are defined in RFCs | recommended, and algorithms defined in RFCs that are not on the
that are not on standards track. Any algorithm listed in the | standards track. Any algorithm listed in the [DNSKEY-IANA] and
[DNSKEY-IANA] and [DS-IANA] registries that are not mentioned in | [DS-IANA] registries that are not mentioned in this document MAY
this document MAY be implemented. For clarification and | be implemented. For clarification and consistency, an algorithm
consistency, an algorithm will be specified as MAY in this | will be specified as MAY in this document only when it has been
document only when it has been downgraded from a MUST or a | downgraded from a MUST or a RECOMMENDED to a MAY.
RECOMMENDED to a MAY.
This update is also reflected in the IANA considerations in This update is also reflected in the IANA considerations in
Section 4. Section 4.
4. IANA Considerations 4. IANA Considerations
In the "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3) In the "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3)
Parameters" registry, the registration procedure for "DNSSEC NSEC3 Parameters" registry, the registration procedure for "DNSSEC NSEC3
Flags", "DNSSEC NSEC3 Hash Algorithms", and "DNSSEC NSEC3PARAM Flags" Flags", "DNSSEC NSEC3 Hash Algorithms", and "DNSSEC NSEC3PARAM Flags"
are changed from "Standards Action" to "RFC Required". has been changed from "Standards Action" to "RFC Required", and this
document has been added as a reference.
In the "Delegation Signer (DS) Resource Record (RR) Type Digest In the "DNSSEC Delegation Signer (DS) Resource Record (RR) Type
Algorithms" registry, the registration procedure for "Digest Digest Algorithms" registry, the registration procedure for "Digest
Algorithms" is changed from "Standards Action" to "RFC Required". Algorithms" has been changed from "Standards Action" to "RFC
Required", and this document has been added as a reference.
5. Security Considerations 5. Security Considerations
Changing the requirements for getting security algorithms added to Changing the requirements for adding security algorithms to IANA
IANA registries as described in this document will make it easier to registries as described in this document will make it easier to add
get good algorithms added to the registries, and will make it easier both good and bad algorithms to the registries. It is impossible to
to get bad algorithms added to the registries. It is impossible to
weigh the security impact of those two changes. weigh the security impact of those two changes.
Administrators of DNSSEC-signed zones, and of validating resolvers, Administrators of DNSSEC-signed zones and validating resolvers may
may have been making security decisions based on the contents of the have been making security decisions based on the contents of the IANA
IANA registries. This was a bad idea in the past, and now is an even 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 worse idea because there will be more algorithms in those registries
that may not have gone through IETF review. Security decisions about that may not have gone through IETF review. Security decisions about
which algorithms are safe and not safe should be made by reading the which algorithms are safe and not safe should be made by reading the
security literature, not by looking in IANA registries. security literature, not by looking in IANA registries.
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 5, line 29 skipping to change at line 211
Requirements and Usage Guidance for DNSSEC", RFC 8624, Requirements and Usage Guidance for DNSSEC", RFC 8624,
DOI 10.17487/RFC8624, June 2019, DOI 10.17487/RFC8624, June 2019,
<https://www.rfc-editor.org/info/rfc8624>. <https://www.rfc-editor.org/info/rfc8624>.
6.2. Informative References 6.2. Informative References
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, DOI 10.17487/RFC3658, December 2003, (RR)", RFC 3658, DOI 10.17487/RFC3658, December 2003,
<https://www.rfc-editor.org/info/rfc3658>. <https://www.rfc-editor.org/info/rfc3658>.
Appendix A. Acknowledgements Acknowledgements
Donald Eastlake, Murray Kucherawy, Dan Harkins, Martin Duke, and Donald Eastlake, Murray Kucherawy, Dan Harkins, Martin Duke, and
Benjamin Kaduk contributed to this document. Benjamin Kaduk contributed to this document.
Author's Address Author's Address
Paul Hoffman Paul Hoffman
ICANN ICANN
Email: paul.hoffman@icann.org Email: paul.hoffman@icann.org
 End of changes. 23 change blocks. 
87 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/