1 Internet Engineering Task Force (IETF) P. Hoffman
2 Request for Comments: 6014 VPN Consortium
3 Updates: 4033, 4034, 4035 November 2010
4 Category: Standards Track
5 ISSN: 2070-1721
6
7
8 Cryptographic Algorithm Identifier Allocation for DNSSEC
9
10 Abstract
11
12 This document specifies how DNSSEC cryptographic algorithm
13 identifiers in the IANA registries are allocated. It changes the
14 requirement from "standard required" to "RFC Required". It does not
15 change the list of algorithms that are recommended or required for
16 DNSSEC implementations.
17
18 Status of This Memo
19
20 This is an Internet Standards Track document.
21
22 This document is a product of the Internet Engineering Task Force
23 (IETF). It represents the consensus of the IETF community. It has
24 received public review and has been approved for publication by the
25 Internet Engineering Steering Group (IESG). Further information on
26 Internet Standards is available in Section 2 of RFC 5741.
27
28 Information about the current status of this document, any errata,
29 and how to provide feedback on it may be obtained at
30 http://www.rfc-editor.org/info/rfc6014.
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Hoffman Standards Track [Page 1]
53 RFC 6014 DNSSEC Alg. Allocation November 2010
54
55
56 Copyright Notice
57
58 Copyright (c) 2010 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 This document may contain material from IETF Documents or IETF
72 Contributions published or made publicly available before November
73 10, 2008. The person(s) controlling the copyright in some of this
74 material may not have granted the IETF Trust the right to allow
75 modifications of such material outside the IETF Standards Process.
76 Without obtaining an adequate license from the person(s) controlling
77 the copyright in such materials, this document may not be modified
78 outside the IETF Standards Process, and derivative works of it may
79 not be created outside the IETF Standards Process, except to format
80 it for publication as an RFC or to translate it into languages other
81 than English.
82
83 1. Introduction
84
85 [RFC2535] specifies that the IANA registry for DNS Security Algorithm
86 Numbers be updated by IETF Standards Action only, with the exception
87 of two values -- 253 and 254. In essence, this means that for an
88 algorithm to get its own entry in the registry, the algorithm must be
89 defined in an RFC on the Standards Track as defined in [RFC2026].
90 The requirement from RFC 2535 is repeated in [RFC3755] and the
91 combination of [RFC4033], [RFC4034], and [RFC4035].
92
93 RFC 2535 allows algorithms that are not on the Standards Track to use
94 private values 253 and 254 in signatures. In each case, an
95 unregistered private name must be included with each use of the
96 algorithm in order to differentiate different algorithms that use the
97 value.
98
99
100
101
102
103
104
105
106
107 Hoffman Standards Track [Page 2]
108 RFC 6014 DNSSEC Alg. Allocation November 2010
109
110
111 2. Requirements for Assignments in the DNS Security Algorithm Numbers
112 Registry
113
114 This document changes the requirement for registration from requiring
115 a Standards Track RFC to requiring a published RFC of any type.
116 There are two reasons for relaxing the requirement:
117
118 o There are some algorithms that are useful that may not be able to
119 be in a Standards Track RFC. For any number of reasons, an
120 algorithm might not have been evaluated thoroughly enough to be
121 able to be put on the Standards Track. Another example is that
122 the algorithm might have unclear intellectual property rights that
123 prevents the algorithm from being put on the Standards Track.
124
125 o Although the size of the registry is restricted (about 250
126 entries), new algorithms are proposed infrequently. It could
127 easily be many decades before there is any reason to consider
128 restricting the registry again.
129
130 Some developers will care about the standards level of the RFCs that
131 are in the registry. The registry has been updated to reflect the
132 current standards level of each algorithm listed.
133
134 To address concerns about the registry eventually filling up, the
135 IETF should re-evaluate the requirements for entry into this registry
136 when approximately 120 of the registry entries have been assigned.
137 That evaluation may lead to tighter restrictions or a new mechanism
138 for extending the size of the registry. In order to make this
139 evaluation more likely, IANA has marked about half of the currently
140 available entries as "Reserved" in order to make the timing for that
141 re-evaluation more apparent.
142
143 The private-use values, 253 and 254, are still useful for developers
144 who want to test, in private, algorithms for which there is no RFC.
145 This document does not change the semantics of those two values.
146
147 3. Expectations for Implementations
148
149 It is important to note that, according to RFC 4034, DNSSEC
150 implementations are not expected to include all of the algorithms
151 listed in the IANA registry; in fact, RFC 4034 and the IANA registry
152 list an algorithm that implementations should not include. This
153 document does nothing to change the expectation that there will be
154 items listed in the IANA registry that need not be (and in some
155 cases, should not be) included in all implementations.
156
157
158
159
160
161
162 Hoffman Standards Track [Page 3]
163 RFC 6014 DNSSEC Alg. Allocation November 2010
164
165
166 There are many reasons why a DNSSEC implementation might not include
167 one or more of the algorithms listed, even those on the Standards
168 Track. In order to be compliant with RFC 4034, an implementation
169 only needs to implement the algorithms listed as mandatory to
170 implement in that standard, or updates to that standard. This
171 document does nothing to change the list of mandatory-to-implement
172 algorithms in RFC 4034. This document does not change the
173 requirements for when an algorithm becomes mandatory to implement.
174 Such requirements should come in a separate, focused document.
175
176 It should be noted that the order of algorithms in the IANA registry
177 does not signify or imply cryptographic strength or preference.
178
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.
The abstract of RFC9157 says that 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 says that it "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."
179 4. IANA Considerations
180
181 This document updates allocation requirements for unassigned values
182 in the "Domain Name System Security (DNSSEC) Algorithm Numbers"
183 registry located at http://www.iana.org/assignments/
184 dns-sec-alg-numbers, in the sub-registry titled "DNS Security
185 Algorithm Numbers". The registration procedure for values that are
186 assigned after this document is published is "RFC Required".
187
188 IANA has marked values 123 through 251 as "Reserved". The registry
189 notes that this reservation is made in RFC 6014 (this RFC) so that
190 when most of the unreserved values are taken, future users and IANA
191 will have a pointer to where the reservation originated and its
192 purpose.
193
194 IANA has added a textual notation to the "References" column in the
195 registry that gives the current standards status for each RFC that is
196 listed in the registry.
197
198 5. Security Considerations
199
200 An algorithm described in an RFC that is not on the Standards Track
201 may have weaker security than one that is on the Standards Track; in
202 fact, that may be the reason that the algorithm was not allowed on
203 Standards Track. Note, however, that not being on the Standards
204 Track does not necessarily mean that an algorithm is weaker.
205 Conversely, algorithms that are on the Standards Track should not
206 necessarily be considered better than algorithms that are not on the
207 Standards Track. There are other reasons (such as intellectual
208 property concerns) that can keep algorithms that are widely
209 considered to be strong off the Standards Track.
210
211
212
213
214
215
216
217 Hoffman Standards Track [Page 4]
218 RFC 6014 DNSSEC Alg. Allocation November 2010
219
220
221 6. References
222
223 6.1. Normative References
224
225 [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
226 RFC 2535, March 1999.
227
228 [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
229 Signer (DS)", RFC 3755, May 2004.
230
231 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
232 Rose, "DNS Security Introduction and Requirements",
233 RFC 4033, March 2005.
234
235 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
236 Rose, "Resource Records for the DNS Security Extensions",
237 RFC 4034, March 2005.
238
239 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
240 Rose, "Protocol Modifications for the DNS Security
241 Extensions", RFC 4035, March 2005.
242
243 6.2. Informative References
244
245 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
246 3", BCP 9, RFC 2026, October 1996.
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272 Hoffman Standards Track [Page 5]
273 RFC 6014 DNSSEC Alg. Allocation November 2010
274
275
276 Appendix A. Experimental and Documentation Values
277
278 During the early discussion of this document, it was proposed that
279 maybe there should be a small number of values reserved for
280 "experimental" purposes. This proposal was not included in this
281 document because of the long history in the IETF of experimental
282 values that became permanent. That is, a developer would release
283 (maybe "experimentally") a version of software that had the
284 experimental value associated with a particular extension,
285 competitors would code their systems to test interoperability, and
286 then no one wanted to change the values in their software to the
287 "real" value that was later assigned.
288
289 There was also a proposal that IANA should reserve two values to be
290 used in documentation only, similar to the way that "example.com" has
291 been reserved as a domain name. That proposal was also not included
292 in this document because all values need to be associated with some
293 algorithm, and there is no problem with having examples that point to
294 commonly deployed algorithms.
295
296 Author's Address
297
298 Paul Hoffman
299 VPN Consortium
300
301 EMail: paul.hoffman@vpnc.org
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327 Hoffman Standards Track [Page 6]
328
Section 2 of RFC9157 says:
Section 4 updates [RFC6014] 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 [RFC6014].