1 Network Working Group J. Jansen
2 Request for Comments: 5702 NLnet Labs
3 Category: Standards Track October 2009
4
5
6 Use of SHA-2 Algorithms with RSA in
7 DNSKEY and RRSIG Resource Records for DNSSEC
8
9 Abstract
10
11 This document describes how to produce RSA/SHA-256 and RSA/SHA-512
12 DNSKEY and RRSIG resource records for use in the Domain Name System
13 Security Extensions (RFC 4033, RFC 4034, and RFC 4035).
14
15 Status of This Memo
16
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
22
23 Copyright Notice
24
25 Copyright (c) 2009 IETF Trust and the persons identified as the
26 document authors. All rights reserved.
27
28 This document is subject to BCP 78 and the IETF Trust's Legal
29 Provisions Relating to IETF Documents
30 (http://trustee.ietf.org/license-info) in effect on the date of
31 publication of this document. Please review these documents
32 carefully, as they describe your rights and restrictions with respect
33 to this document. Code Components extracted from this document must
34 include Simplified BSD License text as described in Section 4.e of
35 the Trust Legal Provisions and are provided without warranty as
36 described in the BSD License.
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Jansen Standards Track [Page 1]
53 RFC 5702 DNSSEC RSA/SHA-2 October 2009
54
55
56 Table of Contents
57
58 1. Introduction ....................................................2
59 2. DNSKEY Resource Records .........................................3
60 2.1. RSA/SHA-256 DNSKEY Resource Records ........................3
61 2.2. RSA/SHA-512 DNSKEY Resource Records ........................3
62 3. RRSIG Resource Records ..........................................3
63 3.1. RSA/SHA-256 RRSIG Resource Records .........................4
64 3.2. RSA/SHA-512 RRSIG Resource Records .........................4
65 4. Deployment Considerations .......................................5
66 4.1. Key Sizes ..................................................5
67 4.2. Signature Sizes ............................................5
68 5. Implementation Considerations ...................................5
69 5.1. Support for SHA-2 Signatures ...............................5
70 5.2. Support for NSEC3 Denial of Existence ......................5
71 6. Examples ........................................................6
72 6.1. RSA/SHA-256 Key and Signature ..............................6
73 6.2. RSA/SHA-512 Key and Signature ..............................7
74 7. IANA Considerations .............................................8
75 8. Security Considerations .........................................8
76 8.1. SHA-1 versus SHA-2 Considerations for RRSIG
77 Resource Records ...........................................8
78 8.2. Signature Type Downgrade Attacks ...........................8
79 9. Acknowledgments .................................................9
80 10. References .....................................................9
81 10.1. Normative References ......................................9
82 10.2. Informative References ....................................9
83
84 1. Introduction
85
86 The Domain Name System (DNS) is the global, hierarchical distributed
87 database for Internet Naming. The DNS has been extended to use
88 cryptographic keys and digital signatures for the verification of the
89 authenticity and integrity of its data. [RFC4033], [RFC4034], and
90 [RFC4035] describe these DNS Security Extensions, called DNSSEC.
91
92 RFC 4034 describes how to store DNSKEY and RRSIG resource records,
93 and specifies a list of cryptographic algorithms to use. This
94 document extends that list with the algorithms RSA/SHA-256 and RSA/
95 SHA-512, and specifies how to store DNSKEY data and how to produce
96 RRSIG resource records with these hash algorithms.
97
98 Familiarity with DNSSEC, RSA, and the SHA-2 [FIPS.180-3.2008] family
99 of algorithms is assumed in this document.
100
101
102
103
104
105
106
107 Jansen Standards Track [Page 2]
108 RFC 5702 DNSSEC RSA/SHA-2 October 2009
109
110
111 To refer to both SHA-256 and SHA-512, this document will use the name
112 SHA-2. This is done to improve readability. When a part of text is
113 specific for either SHA-256 or SHA-512, their specific names are
114 used. The same goes for RSA/SHA-256 and RSA/SHA-512, which will be
115 grouped using the name RSA/SHA-2.
116
117 The term "SHA-2" is not officially defined but is usually used to
118 refer to the collection of the algorithms SHA-224, SHA-256, SHA-384,
119 and SHA-512. Since SHA-224 and SHA-384 are not used in DNSSEC, SHA-2
120 will only refer to SHA-256 and SHA-512 in this document.
121
122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
124 document are to be interpreted as described in [RFC2119].
125
126 2. DNSKEY Resource Records
127
128 The format of the DNSKEY RR can be found in [RFC4034]. [RFC3110]
129 describes the use of RSA/SHA-1 for DNSSEC signatures.
130
131 2.1. RSA/SHA-256 DNSKEY Resource Records
132
133 RSA public keys for use with RSA/SHA-256 are stored in DNSKEY
134 resource records (RRs) with the algorithm number 8.
135
136 For interoperability, as in [RFC3110], the key size of RSA/SHA-256
137 keys MUST NOT be less than 512 bits and MUST NOT be more than 4096
138 bits.
139
140 2.2. RSA/SHA-512 DNSKEY Resource Records
141
142 RSA public keys for use with RSA/SHA-512 are stored in DNSKEY
143 resource records (RRs) with the algorithm number 10.
144
145 The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits and
146 MUST NOT be more than 4096 bits.
147
148 3. RRSIG Resource Records
149
150 The value of the signature field in the RRSIG RR follows the RSASSA-
151 PKCS1-v1_5 signature scheme and is calculated as follows. The values
152 for the RDATA fields that precede the signature data are specified in
153 [RFC4034].
154
155
156
157
158
159
160
161
162 Jansen Standards Track [Page 3]
163 RFC 5702 DNSSEC RSA/SHA-2 October 2009
164
165
166 hash = SHA-XXX(data)
167
168 Here XXX is either 256 or 512, depending on the algorithm used, as
169 specified in FIPS PUB 180-3; "data" is the wire format data of the
170 resource record set that is signed, as specified in [RFC4034].
171
172 signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
173
174 Here "|" is concatenation; "00", "01", "FF", and "00" are fixed
175 octets of corresponding hexadecimal value; "e" is the private
176 exponent of the signing RSA key; and "n" is the public modulus of the
177 signing key. The FF octet MUST be repeated the exact number of times
178 so that the total length of the concatenated term in parentheses
179 equals the length of the modulus of the signer's public key ("n").
180
181 The "prefix" is intended to make the use of standard cryptographic
182 libraries easier. These specifications are taken directly from the
183 specifications of RSASSA-PKCS1-v1_5 in PKCS #1 v2.1 (Section 8.2 of
184 [RFC3447]), and EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 (Section 9.2
185 of [RFC3447]). The prefixes for the different algorithms are
186 specified below.
187
188 3.1. RSA/SHA-256 RRSIG Resource Records
189
190 RSA/SHA-256 signatures are stored in the DNS using RRSIG resource
191 records (RRs) with algorithm number 8.
192
193 The prefix is the ASN.1 DER SHA-256 algorithm designator prefix, as
194 specified in PKCS #1 v2.1 [RFC3447]:
195
196 hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
197
198 3.2. RSA/SHA-512 RRSIG Resource Records
199
200 RSA/SHA-512 signatures are stored in the DNS using RRSIG resource
201 records (RRs) with algorithm number 10.
202
203 The prefix is the ASN.1 DER SHA-512 algorithm designator prefix, as
204 specified in PKCS #1 v2.1 [RFC3447]:
205
206 hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40
207
208
209
210
211
212
213
214
215
216
217 Jansen Standards Track [Page 4]
218 RFC 5702 DNSSEC RSA/SHA-2 October 2009
219
220
221 4. Deployment Considerations
222
223 4.1. Key Sizes
224
225 Apart from the restrictions in Section 2, this document will not
226 specify what size of keys to use. That is an operational issue and
227 depends largely on the environment and intended use. A good starting
228 point for more information would be NIST SP 800-57 [NIST800-57].
229
230 4.2. Signature Sizes
231
232 In this family of signing algorithms, the size of signatures is
233 related to the size of the key and not to the hashing algorithm used
234 in the signing process. Therefore, RRSIG resource records produced
235 with RSA/SHA-256 or RSA/SHA-512 will have the same size as those
236 produced with RSA/SHA-1, if the keys have the same length.
237
238 5. Implementation Considerations
239
240 5.1. Support for SHA-2 Signatures
241
242 DNSSEC-aware implementations SHOULD be able to support RRSIG and
243 DNSKEY resource records created with the RSA/SHA-2 algorithms as
244 defined in this document.
245
246 5.2. Support for NSEC3 Denial of Existence
247
248 [RFC5155] defines new algorithm identifiers for existing signing
249 algorithms, to indicate that zones signed with these algorithm
250 identifiers can use NSEC3 as well as NSEC records to provide denial
251 of existence. That mechanism was chosen to protect implementations
252 predating RFC 5155 from encountering resource records about which
253 they could not know. This document does not define such algorithm
254 aliases.
255
256 A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate
257 negative answers in the form of both NSEC and NSEC3 with hash
258 algorithm 1, as defined in [RFC5155]. An authoritative server that
259 does not implement NSEC3 MAY still serve zones that use RSA/SHA-2
260 with NSEC denial of existence.
261
262
263
264
265
266
267
268
269
270
271
272 Jansen Standards Track [Page 5]
273 RFC 5702 DNSSEC RSA/SHA-2 October 2009
274
275
276 6. Examples
277
278 6.1. RSA/SHA-256 Key and Signature
279
280 Given a private key with the following values (in Base64):
281
282 Private-key-format: v1.2
283 Algorithm: 8 (RSASHA256)
284 Modulus: wVwaxrHF2CK64aYKRUibLiH30KpPuPBjel7E8ZydQW1HYWHfoGm
285 idzC2RnhwCC293hCzw+TFR2nqn8OVSY5t2Q==
286 PublicExponent: AQAB
287 PrivateExponent: UR44xX6zB3eaeyvTRzmskHADrPCmPWnr8dxsNwiDGHzrMKLN+i/
288 HAam+97HxIKVWNDH2ba9Mf1SA8xu9dcHZAQ==
289 Prime1: 4c8IvFu1AVXGWeFLLFh5vs7fbdzdC6U82fduE6KkSWk=
290 Prime2: 2zZpBE8ZXVnL74QjG4zINlDfH+EOEtjJJ3RtaYDugvE=
291 Exponent1: G2xAPFfK0KGxGANDVNxd1K1c9wOmmJ51mGbzKFFNMFk=
292 Exponent2: GYxP1Pa7CAwtHm8SAGX594qZVofOMhgd6YFCNyeVpKE=
293 Coefficient: icQdNRjlZGPmuJm2TIadubcO8X7V4y07aVhX464tx8Q=
294
295 The DNSKEY record for this key would be:
296
297 example.net. 3600 IN DNSKEY (256 3 8 AwEAAcFcGsaxxdgiuuGmCkVI
298 my4h99CqT7jwY3pexPGcnUFtR2Fh36BponcwtkZ4cAgtvd4Qs8P
299 kxUdp6p/DlUmObdk= );{id = 9033 (zsk), size = 512b}
300
301 With this key, sign the following RRSet, consisting of 1 A record:
302
303 www.example.net. 3600 IN A 192.0.2.91
304
305 If the inception date is set at 00:00 hours on January 1st, 2000, and
306 the expiration date at 00:00 hours on January 1st, 2030, the
307 following signature should be created:
308
309 www.example.net. 3600 IN RRSIG (A 8 3 3600 20300101000000
310 20000101000000 9033 example.net. kRCOH6u7l0QGy9qpC9
311 l1sLncJcOKFLJ7GhiUOibu4teYp5VE9RncriShZNz85mwlMgNEa
312 cFYK/lPtPiVYP4bwg==);{id = 9033}
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327 Jansen Standards Track [Page 6]
328 RFC 5702 DNSSEC RSA/SHA-2 October 2009
329
330
331 6.2. RSA/SHA-512 Key and Signature
332
333 Given a private key with the following values (in Base64):
334
335 Private-key-format: v1.2
336 Algorithm: 10 (RSASHA512)
337 Modulus: 0eg1M5b563zoq4k5ZEOnWmd2/BvpjzedJVdfIsDcMuuhE5SQ3pf
338 Q7qmdaeMlC6Nf8DKGoUPGPXe06cP27/WRODtxXquSUytkO0kJDk
339 8KX8PtA0+yBWwy7UnZDyCkynO00Uuk8HPVtZeMO1pHtlAGVnc8V
340 jXZlNKdyit99waaE4s=
341 PublicExponent: AQAB
342 PrivateExponent: rFS1IPbJllFFgFc33B5DDlC1egO8e81P4fFadODbp56V7sphKa6
343 AZQCx8NYAew6VXFFPAKTw41QdHnK5kIYOwxvfFDjDcUGza88qbj
344 yrDPSJenkeZbISMUSSqy7AMFzEolkk6WSn6k3thUVRgSlqDoOV3
345 SEIAsrB043XzGrKIVE=
346 Prime1: 8mbtsu9Tl9v7tKSHdCIeprLIQXQLzxlSZun5T1n/OjvXSUtvD7x
347 nZJ+LHqaBj1dIgMbCq2U8O04QVcK3TS9GiQ==
348 Prime2: 3a6gkfs74d0Jb7yL4j4adAif4fcp7ZrGt7G5NRVDDY/Mv4TERAK
349 Ma0TKN3okKE0A7X+Rv2K84mhT4QLDlllEcw==
350 Exponent1: v3D5A9uuCn5rgVR7wgV8ba0/KSpsdSiLgsoA42GxiB1gvvs7gJM
351 MmVTDu/ZG1p1ZnpLbhh/S/Qd/MSwyNlxC+Q==
352 Exponent2: m+ezf9dsDvYQK+gzjOLWYeKq5xWYBEYFGa3BLocMiF4oxkzOZ3J
353 PZSWU/h1Fjp5RV7aPP0Vmx+hNjYMPIQ8Y5w==
354 Coefficient: Je5YhYpUron/WdOXjxNAxDubAp3i5X7UOUfhJcyIggqwY86IE0Q
355 /Bk0Dw4SC9zxnsimmdBXW2Izd8Lwuk8FQcQ==
356
357 The DNSKEY record for this key would be:
358
359 example.net. 3600 IN DNSKEY (256 3 10 AwEAAdHoNTOW+et86KuJOWRD
360 p1pndvwb6Y83nSVXXyLA3DLroROUkN6X0O6pnWnjJQujX/AyhqFD
361 xj13tOnD9u/1kTg7cV6rklMrZDtJCQ5PCl/D7QNPsgVsMu1J2Q8g
362 pMpztNFLpPBz1bWXjDtaR7ZQBlZ3PFY12ZTSncorffcGmhOL
363 );{id = 3740 (zsk), size = 1024b}
364
365 With this key, sign the following RRSet, consisting of 1 A record:
366
367 www.example.net. 3600 IN A 192.0.2.91
368
369 If the inception date is set at 00:00 hours on January 1st, 2000, and
370 the expiration date at 00:00 hours on January 1st, 2030, the
371 following signature should be created:
372
373 www.example.net. 3600 IN RRSIG (A 10 3 3600 20300101000000
374 20000101000000 3740 example.net. tsb4wnjRUDnB1BUi+t
375 6TMTXThjVnG+eCkWqjvvjhzQL1d0YRoOe0CbxrVDYd0xDtsuJRa
376 eUw1ep94PzEWzr0iGYgZBWm/zpq+9fOuagYJRfDqfReKBzMweOL
377 DiNa8iP5g9vMhpuv6OPlvpXwm9Sa9ZXIbNl1MBGk0fthPgxdDLw
378 =);{id = 3740}
379
380
381
382 Jansen Standards Track [Page 7]
383 RFC 5702 DNSSEC RSA/SHA-2 October 2009
384
385
386 7. IANA Considerations
387
388 This document updates the IANA registry "DNS SECURITY ALGORITHM
389 NUMBERS -- per [RFC4035]" (http://www.iana.org/protocols). The
390 following entries are added to the registry:
391
392 Zone Trans.
393 Value Description Mnemonic Signing Sec. References
394 8 RSA/SHA-256 RSASHA256 Y * RFC 5702
395 10 RSA/SHA-512 RSASHA512 Y * RFC 5702
396
397 * There has been no determination of standardization of the use of
398 this algorithm with Transaction Security.
399
400 8. Security Considerations
401
402 8.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource Records
403
404 Users of DNSSEC are encouraged to deploy SHA-2 as soon as software
405 implementations allow for it. SHA-2 is widely believed to be more
406 resilient to attack than SHA-1, and confidence in SHA-1's strength is
407 being eroded by recently announced attacks. Regardless of whether or
408 not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
409 time of this writing) that SHA-2 is the better choice for use in
410 DNSSEC records.
411
412 SHA-2 is considered sufficiently strong for the immediate future, but
413 predictions about future development in cryptography and
414 cryptanalysis are beyond the scope of this document.
415
416 The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one
417 used for RSA/SHA-1 signatures. This should ease implementation of
418 the new hashing algorithms in DNSSEC software.
419
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.
This RFC is implemented in BIND 9.18 (all versions).
420 8.2. Signature Type Downgrade Attacks
421
422 Since each RRSet MUST be signed with each algorithm present in the
423 DNSKEY RRSet at the zone apex (see Section 2.2 of [RFC4035]), a
424 malicious party cannot filter out the RSA/SHA-2 RRSIG and force the
425 validator to use the RSA/SHA-1 signature if both are present in the
426 zone. This should provide resilience against algorithm downgrade
427 attacks, if the validator supports RSA/SHA-2.
428
429
430
431
432
433
434
435
436
437 Jansen Standards Track [Page 8]
438 RFC 5702 DNSSEC RSA/SHA-2 October 2009
439
440
441 9. Acknowledgments
442
443 This document is a minor extension to [RFC4034]. Also, we try to
444 follow the documents [RFC3110] and [RFC4509] for consistency. The
445 authors of and contributors to these documents are gratefully
446 acknowledged for their hard work.
447
448 The following people provided additional feedback and text: Jaap
449 Akkerhuis, Mark Andrews, Roy Arends, Rob Austein, Francis Dupont,
450 Miek Gieben, Alfred Hoenes, Paul Hoffman, Peter Koch, Scott Rose,
451 Michael St. Johns, and Wouter Wijngaards.
452
453 10. References
454
455 10.1. Normative References
456
457 [FIPS.180-3.2008]
458 National Institute of Standards and Technology, "Secure
459 Hash Standard", FIPS PUB 180-3, October 2008.
460
461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
462 Requirement Levels", BCP 14, RFC 2119, March 1997.
463
464 [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
465 Name System (DNS)", RFC 3110, May 2001.
466
467 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
468 Rose, "DNS Security Introduction and Requirements",
469 RFC 4033, March 2005.
470
471 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
472 Rose, "Resource Records for the DNS Security Extensions",
473 RFC 4034, March 2005.
474
475 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
476 Rose, "Protocol Modifications for the DNS Security
477 Extensions", RFC 4035, March 2005.
478
479 10.2. Informative References
480
481 [NIST800-57]
482 Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
483 "Recommendations for Key Management", NIST SP 800-57,
484 March 2007.
485
486 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
487 Standards (PKCS) #1: RSA Cryptography Specifications
488 Version 2.1", RFC 3447, February 2003.
489
490
491
492 Jansen Standards Track [Page 9]
493 RFC 5702 DNSSEC RSA/SHA-2 October 2009
494
495
496 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
497 (DS) Resource Records (RRs)", RFC 4509, May 2006.
498
499 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
500 Security (DNSSEC) Hashed Authenticated Denial of
501 Existence", RFC 5155, March 2008.
502
503 Author's Address
504
505 Jelte Jansen
506 NLnet Labs
507 Science Park 140
508 1098 XG Amsterdam
509 NL
510
511 EMail: jelte@NLnetLabs.nl
512 URI: http://www.nlnetlabs.nl/
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547 Jansen Standards Track [Page 10]
548
8.2. Signature Type Downgrade Attacks Since each RRSet MUST be signed with each algorithm present in the DNSKEY RRSet at the zone apex (see Section 2.2 of [RFC4035]), a malicious party cannot filter out the RSA/SHA-2 RRSIG and force the validator to use the RSA/SHA-1 signature if both are present in the zone. This should provide resilience against algorithm downgrade attacks, if the validator supports RSA/SHA-2.
[none]
The section is incorrect in its entirety. Although the requirement on signers does exist, there is no related requirement for validators to check that all signature algorithms are present. RFC6840 5.11 (which I do realise is newer than RFC5702) re-states this explicitly, where RFC4035 merely implied this distinction.