1 Internet Engineering Task Force (IETF) S. Rose
2 Request for Comments: 6944 NIST
3 Updates: 2536, 2539, 3110, 4034, 4398, April 2013
4 5155, 5702, 5933
5 Category: Standards Track
6 ISSN: 2070-1721
7
8
9 Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm
10 Implementation Status
11
12 Abstract
13
14 The DNS Security Extensions (DNSSEC) requires the use of
15 cryptographic algorithm suites for generating digital signatures over
16 DNS data. There is currently an IANA registry for these algorithms,
17 but there is no record of the recommended implementation status of
18 each algorithm. This document provides an applicability statement on
19 algorithm implementation status for DNSSEC component software. This
20 document lists each algorithm's status based on the current
21 reference. In the case that an algorithm is specified without an
22 implementation status, this document assigns one. This document
23 updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933.
24
25 Status of This Memo
26
27 This is an Internet Standards Track document.
28
29 This document is a product of the Internet Engineering Task Force
30 (IETF). It represents the consensus of the IETF community. It has
31 received public review and has been approved for publication by the
32 Internet Engineering Steering Group (IESG). Further information on
33 Internet Standards is available in Section 2 of RFC 5741.
34
35 Information about the current status of this document, any errata,
36 and how to provide feedback on it may be obtained at
37 http://www.rfc-editor.org/info/rfc6944.
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Rose Standards Track [Page 1]
53 RFC 6944 DNSSEC DNSKEY Algorithm Status April 2013
54
55
56 Copyright Notice
57
58 Copyright (c) 2013 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 Table of Contents
72
73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
74 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
75 2. The DNS Security Algorithm Implementation Status Lists . . . . 3
76 2.1. Status Definitions . . . . . . . . . . . . . . . . . . . . 3
77 2.2. Algorithm Implementation Status Assignment Rationale . . . 4
78 2.3. DNSSEC Implementation Status Table . . . . . . . . . . . . 4
79 2.4. Specifying New Algorithms and Updating the Status of
80 Existing Entries . . . . . . . . . . . . . . . . . . . . . 5
81 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
82 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
83 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
84 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6
85 5.2. Informative References . . . . . . . . . . . . . . . . . . 7
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Rose Standards Track [Page 2]
108 RFC 6944 DNSSEC DNSKEY Algorithm Status April 2013
109
110
111 1. Introduction
112
113 The Domain Name System (DNS) Security Extensions (DNSSEC) ([RFC4033],
114 [RFC4034], [RFC4035], [RFC4509], [RFC5155], and [RFC5702]) uses
115 digital signatures over DNS data to provide source authentication and
116 integrity protection. DNSSEC uses an IANA registry to list codes for
117 digital signature algorithms (consisting of a cryptographic algorithm
118 and one-way hash function).
119
120 The original list of algorithm status is found in [RFC4034]. Other
121 DNSSEC RFCs have added new algorithms or changed the status of
122 algorithms in the registry. However, implementers must read through
123 all the documents in order to discover which algorithms are
124 considered wise to implement, which are not, and which algorithms may
125 become widely used in the future.
126
127 This document defines the current implementation status for all
128 registered algorithms. If the status of algorithms changes, this
129 document will be replaced with a new one establishing the new status;
130 see Section 2.4.
131
132 This document updates the following: [RFC2536], [RFC2539], [RFC3110],
133 [RFC4034], [RFC4398], [RFC5155], [RFC5702], and [RFC5933].
134
135 1.1. Requirements Language
136
137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
139 document are to be interpreted as described in [RFC2119].
140
141 2. The DNS Security Algorithm Implementation Status Lists
142
143 2.1. Status Definitions
144
145 Must Implement: The algorithm MUST be implemented to interoperate
146 with other implementations of this specification.
147
148 Must Not Implement: The algorithm MUST NOT be implemented. An
149 algorithm with this status has known weaknesses.
150
151 Recommended to Implement: The algorithm SHOULD be implemented.
152 Utility and interoperability with other implementations will be
153 improved when an algorithm with this status is implemented, though
154 there might be occasions where it is reasonable not to implement
155 the algorithm. An implementer must understand and weigh the full
156 implications of choosing not to implement this particular
157 algorithm.
158
159
160
161
162 Rose Standards Track [Page 3]
163 RFC 6944 DNSSEC DNSKEY Algorithm Status April 2013
164
165
166 Optional: The algorithm MAY be implemented, but all implementations
167 MUST be prepared to interoperate with implementations that do or
168 do not implement this algorithm.
169
170 2.2. Algorithm Implementation Status Assignment Rationale
171
172 RSASHA1 has an implementation status of Must Implement, consistent
173 with [RFC4034]. RSAMD5 has an implementation status of Must Not
174 Implement because of known weaknesses in MD5.
175
176 The status of RSASHA1-NSEC3-SHA1 is set to Recommended to Implement
177 as many deployments use NSEC3. The status of RSA/SHA-256 and RSA/
178 SHA-512 are also set to Recommended to Implement as major deployments
179 (such as the root zone) use these algorithms [ROOTDPS]. It is
180 believed that RSA/SHA-256 or RSA/SHA-512 algorithms will replace
181 older algorithms (e.g., RSA/SHA-1) that have a perceived weakness.
182
183 Likewise, ECDSA with the two identified curves (ECDSAP256SHA256 and
184 ECDSAP384SHA384) is an algorithm that may see widespread use due to
185 the perceived similar level of security offered with smaller key size
186 compared to the key sizes of algorithms such as RSA. Therefore,
187 ECDSAP256SHA256 and ECDSAP384SHA384 are Recommended to Implement.
188
189 All other algorithms used in DNSSEC specified without an
190 implementation status are currently set to Optional.
191
192 2.3. DNSSEC Implementation Status Table
193
194 The DNSSEC algorithm implementation status table is listed below.
195 Only the algorithms already specified for use with DNSSEC at the time
196 of writing are listed.
197
198 +------------+------------+-------------------+-------------------+
199 | Must | Must Not | Recommended | Optional |
200 | Implement | Implement | to Implement | |
201 +------------+------------+-------------------+-------------------+
202 | | | | |
203 | RSASHA1 | RSAMD5 | RSASHA256 | Any |
204 | | | RSASHA1-NSEC3 | registered |
205 | | | -SHA1 | algorithm |
206 | | | RSASHA512 | not listed in |
207 | | | ECDSAP256SHA256 | this table |
208 | | | ECDSAP384SHA384 | |
209 +------------+------------+-------------------+-------------------+
210
211
212
213
214
215
216
217 Rose Standards Track [Page 4]
218 RFC 6944 DNSSEC DNSKEY Algorithm Status April 2013
219
220
221 This table does not list the Reserved values in the IANA registry
222 table or the values for INDIRECT (252), PRIVATE (253), and PRIVATEOID
223 (254). These values may relate to more than one algorithm and are
224 therefore up to the implementer's discretion. As noted, any
225 algorithm not listed in the table is Optional. As of this writing,
226 the Optional algorithms are DSASHA1, DH, DSA-NSEC3-SHA1, and GOST-
227 ECC, but in general, anything not explicitly listed is Optional.
228
229 2.4. Specifying New Algorithms and Updating the Status of Existing
230 Entries
231
232 [RFC6014] establishes a parallel procedure for adding a registry
233 entry for a new algorithm other than a standards track document.
234 Because any algorithm not listed in the foregoing table is Optional,
235 algorithms entered into the registry using the [RFC6014] procedure
236 are automatically Optional.
237
238 It has turned out to be useful for implementations to refer to a
239 single document that specifies the implementation status of every
240 algorithm. Accordingly, when a new algorithm is to be registered
241 with a status other than Optional, this document shall be made
242 obsolete by a new document that adds the new algorithm to the table
243 in Section 2.3. Similarly, if the status of any algorithm in the
244 table in Section 2.3 changes, a new document shall make this document
245 obsolete; that document shall include a replacement of the table in
246 Section 2.3. This way, the goal of having one authoritative document
247 to specify all the status values is achieved.
248
249 This document cannot be updated, only made obsolete and replaced by a
250 successor document.
251
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.
252 3. IANA Considerations
253
254 This document lists the implementation status of cryptographic
255 algorithms used with DNSSEC. These algorithms are maintained in an
256 IANA registry at http://www.iana.org/assignments/dns-sec-alg-numbers.
257 Because this document establishes the implementation status of every
258 algorithm, it has been listed as a reference for the registry itself.
259
260 4. Security Considerations
261
262 This document lists, and in some cases assigns, the implementation
263 status of cryptographic algorithms used with DNSSEC. It is not meant
264 to be a discussion on algorithm superiority. No new security
265 considerations are raised in this document, though prior description
266 of algorithms as NOT RECOMMENDED (see [RFC4034]) has been recast as
267 Must Not Implement.
268
269
270
271
272 Rose Standards Track [Page 5]
273 RFC 6944 DNSSEC DNSKEY Algorithm Status April 2013
274
275
276 5. References
277
This document lists the implementation status of cryptographic algorithms used with DNSSEC. These algorithms are maintained in an IANA registry at http://www.iana.org/assignments/dns-sec-alg-numbers. Because this document establishes the implementation status of every algorithm, it has been listed as a reference for the registry itself.
This document lists the implementation status of cryptographic algorithms used with DNSSEC. These algorithms are maintained in an IANA registry at http://www.iana.org/assignments/dns-sec-alg-numbers. Because this document establishes the implementation status of every algorithm, it has been listed as a reference for the registry itself. Given significance of status change of RSAMD5 algorithm, a reference to this RFC should be added to the registry.
278 5.1. Normative References
279
280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
281 Requirement Levels", BCP 14, RFC 2119, March 1997.
282
283 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
284 (DNS)", RFC 2536, March 1999.
285
286 [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
287 Domain Name System (DNS)", RFC 2539, March 1999.
288
289 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
290 Name System (DNS)", RFC 3110, May 2001.
291
292 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
293 Rose, "DNS Security Introduction and Requirements",
294 RFC 4033, March 2005.
295
296 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
297 Rose, "Resource Records for the DNS Security Extensions",
298 RFC 4034, March 2005.
299
300 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
301 Rose, "Protocol Modifications for the DNS Security
302 Extensions", RFC 4035, March 2005.
303
304 [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name
305 System (DNS)", RFC 4398, March 2006.
306
307 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
308 (DS) Resource Records (RRs)", RFC 4509, May 2006.
309
310 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
311 Security (DNSSEC) Hashed Authenticated Denial of
312 Existence", RFC 5155, March 2008.
313
314 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
315 and RRSIG Resource Records for DNSSEC", RFC 5702,
316 October 2009.
317
318 [RFC5933] Dolmatov, V., Chuprina, A., and I. Ustinov, "Use of GOST
319 Signature Algorithms in DNSKEY and RRSIG Resource Records
320 for DNSSEC", RFC 5933, July 2010.
321
322 [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier
323 Allocation for DNSSEC", RFC 6014, November 2010.
324
325
326
327 Rose Standards Track [Page 6]
328 RFC 6944 DNSSEC DNSKEY Algorithm Status April 2013
329
330
331 5.2. Informative References
332
333 [ROOTDPS] Ljunggren, F., Okubo, T., Lamb, R., and J. Schlyter,
334 "DNSSEC Practice Statement for the Root Zone KSK
335 Operator", DNS ROOTDPS, May 2010,
336 <http://www.root-dnssec.org/wp-content/uploads/2010/06/
337 icann-dps-00.txt>.
338
339 Author's Address
340
341 Scott Rose
342 NIST
343 100 Bureau Dr.
344 Gaithersburg, MD 20899
345 USA
346
347 Phone: +1-301-975-8439
348 EMail: scottr.nist@gmail.com
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382 Rose Standards Track [Page 7]
383
N/A
[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital Signature
Algorithm (DSA) for DNSSEC", RFC 6605, April 2012.