1 Internet Engineering Task Force (IETF) P. Hoffman
2 Request for Comments: 9157 ICANN
3 Updates: 5155, 6014, 8624 November 2021
4 Category: Standards Track
5 ISSN: 2070-1721
6
7
8 Revised IANA Considerations for DNSSEC
9
10 Abstract
11
12 This document changes the review requirements needed to get DNSSEC
13 algorithms and resource records added to IANA registries. It updates
14 RFC 6014 to include hash algorithms for Delegation Signer (DS)
15 records and NextSECure version 3 (NSEC3) parameters (for Hashed
16 Authenticated Denial of Existence). It also updates RFCs 5155 and
17 6014, which have requirements for DNSSEC algorithms, and updates RFC
18 8624 to clarify the implementation recommendation related to the
19 algorithms described in RFCs that are not on the standards track.
20 The rationale for these changes is to bring the requirements for DS
21 records and hash algorithms used in NSEC3 in line with the
22 requirements for all other DNSSEC algorithms.
23
24 Status of This Memo
25
26 This is an Internet Standards Track document.
27
28 This document is a product of the Internet Engineering Task Force
29 (IETF). It represents the consensus of the IETF community. It has
30 received public review and has been approved for publication by the
31 Internet Engineering Steering Group (IESG). Further information on
32 Internet Standards is available in Section 2 of RFC 7841.
33
34 Information about the current status of this document, any errata,
35 and how to provide feedback on it may be obtained at
36 https://www.rfc-editor.org/info/rfc9157.
37
38 Copyright Notice
39
40 Copyright (c) 2021 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
42
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (https://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Revised BSD License text as described in Section 4.e of the
50 Trust Legal Provisions and are provided without warranty as described
51 in the Revised BSD License.
52
53 Table of Contents
54
55 1. Introduction
56 1.1. Requirements Language
57 2. Update to RFC 6014
58 3. Update to RFC 8624
59 4. IANA Considerations
60 5. Security Considerations
61 6. References
62 6.1. Normative References
63 6.2. Informative References
64 Acknowledgements
65 Author's Address
66
67 1. Introduction
68
69 DNSSEC is primarily described in [RFC4033], [RFC4034], and [RFC4035].
70 DNSSEC commonly uses another resource record beyond those defined in
71 [RFC4034]: NSEC3 [RFC5155]. DS resource records were originally
72 defined in [RFC3658], and that definition was obsoleted by [RFC4034].
73
74 [RFC6014] updates the requirements for how DNSSEC cryptographic
75 algorithm identifiers in the IANA registries are assigned, reducing
76 the requirements from "Standards Action" to "RFC Required". However,
77 the IANA registry requirements for hash algorithms for DS records
78 [RFC3658] and for the hash algorithms used in NSEC3 records [RFC5155]
79 are still "Standards Action". This document updates those IANA
80 registry requirements. (For a reference on how IANA registries can
81 be updated in general, see [RFC8126].)
82
83 1.1. Requirements Language
84
85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
87 "OPTIONAL" in this document are to be interpreted as described in
88 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
89 capitals, as shown here.
90
91 2. Update to RFC 6014
92
93 Section 4 updates [RFC6014] to bring the requirements for DS records
94 and NSEC3 hash algorithms in line with the rest of the DNSSEC
95 cryptographic algorithms by allowing any DS hash algorithms, NSEC3
96 hash algorithms, NSEC3 parameters, and NSEC3 flags that are fully
97 described in an RFC to have identifiers assigned in the IANA
98 registries. This is an addition to the IANA considerations in
99 [RFC6014].
100
101 3. Update to RFC 8624
102
103 This document updates [RFC8624] for all DNSKEY and DS algorithms that
104 are not on the standards track.
105
106 The second paragraph of Section 1.2 of [RFC8624] currently says:
107
108 | This document only provides recommendations with respect to
109 | mandatory-to-implement algorithms or algorithms so weak that they
110 | cannot be recommended. Any algorithm listed in the [DNSKEY-IANA]
111 | and [DS-IANA] registries that are not mentioned in this document
112 | MAY be implemented. For clarification and consistency, an
113 | algorithm will be specified as MAY in this document only when it
114 | has been downgraded from a MUST or a RECOMMENDED to a MAY.
115
116 That paragraph is now replaced with the following:
117
118 | This document provides recommendations with respect to mandatory-
119 | to-implement algorithms, algorithms so weak that they cannot be
120 | recommended, and algorithms defined in RFCs that are not on the
121 | standards track. Any algorithm listed in the [DNSKEY-IANA] and
122 | [DS-IANA] registries that are not mentioned in this document MAY
123 | be implemented. For clarification and consistency, an algorithm
124 | will be specified as MAY in this document only when it has been
125 | downgraded from a MUST or a RECOMMENDED to a MAY.
126
127 This update is also reflected in the IANA considerations in
128 Section 4.
129
130 4. IANA Considerations
131
132 In the "Domain Name System Security (DNSSEC) NextSECure3 (NSEC3)
133 Parameters" registry, the registration procedure for "DNSSEC NSEC3
134 Flags", "DNSSEC NSEC3 Hash Algorithms", and "DNSSEC NSEC3PARAM Flags"
135 has been changed from "Standards Action" to "RFC Required", and this
136 document has been added as a reference.
137
138 In the "DNSSEC Delegation Signer (DS) Resource Record (RR) Type
139 Digest Algorithms" registry, the registration procedure for "Digest
140 Algorithms" has been changed from "Standards Action" to "RFC
141 Required", and this document has been added as a reference.
142
143 5. Security Considerations
144
145 Changing the requirements for adding security algorithms to IANA
146 registries as described in this document will make it easier to add
147 both good and bad algorithms to the registries. It is impossible to
148 weigh the security impact of those two changes.
149
150 Administrators of DNSSEC-signed zones and validating resolvers may
151 have been making security decisions based on the contents of the IANA
152 registries. This was a bad idea in the past, and now it is an even
153 worse idea because there will be more algorithms in those registries
154 that may not have gone through IETF review. Security decisions about
155 which algorithms are safe and not safe should be made by reading the
156 security literature, not by looking in IANA registries.
157
158 6. References
159
160 6.1. Normative References
161
162 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
163 Requirement Levels", BCP 14, RFC 2119,
164 DOI 10.17487/RFC2119, March 1997,
165 <https://www.rfc-editor.org/info/rfc2119>.
166
167 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
168 Rose, "DNS Security Introduction and Requirements",
169 RFC 4033, DOI 10.17487/RFC4033, March 2005,
170 <https://www.rfc-editor.org/info/rfc4033>.
171
172 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
173 Rose, "Resource Records for the DNS Security Extensions",
174 RFC 4034, DOI 10.17487/RFC4034, March 2005,
175 <https://www.rfc-editor.org/info/rfc4034>.
176
177 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
178 Rose, "Protocol Modifications for the DNS Security
179 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
180 <https://www.rfc-editor.org/info/rfc4035>.
181
182 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
183 Security (DNSSEC) Hashed Authenticated Denial of
184 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
185 <https://www.rfc-editor.org/info/rfc5155>.
186
187 [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier
188 Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014,
189 November 2010, <https://www.rfc-editor.org/info/rfc6014>.
190
191 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
192 Writing an IANA Considerations Section in RFCs", BCP 26,
193 RFC 8126, DOI 10.17487/RFC8126, June 2017,
194 <https://www.rfc-editor.org/info/rfc8126>.
195
196 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
197 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
198 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
199
200 [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation
201 Requirements and Usage Guidance for DNSSEC", RFC 8624,
202 DOI 10.17487/RFC8624, June 2019,
203 <https://www.rfc-editor.org/info/rfc8624>.
204
205 6.2. Informative References
206
207 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
208 (RR)", RFC 3658, DOI 10.17487/RFC3658, December 2003,
209 <https://www.rfc-editor.org/info/rfc3658>.
210
211 Acknowledgements
212
213 Donald Eastlake, Murray Kucherawy, Dan Harkins, Martin Duke, and
214 Benjamin Kaduk contributed to this document.
215
216 Author's Address
217
218 Paul Hoffman
219 ICANN
220
221 Email: paul.hoffman@icann.org
222
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.