1 Internet Engineering Task Force (IETF) P. Hoffman
2 Request for Comments: 6605 VPN Consortium
3 Category: Standards Track W.C.A. Wijngaards
4 ISSN: 2070-1721 NLnet Labs
5 April 2012
6
7
8 Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC
9
10 Abstract
11
12 This document describes how to specify Elliptic Curve Digital
13 Signature Algorithm (DSA) keys and signatures in DNS Security
14 (DNSSEC). It lists curves of different sizes and uses the SHA-2
15 family of hashes for signatures.
16
17 Status of This Memo
18
19 This is an Internet Standards Track document.
20
21 This document is a product of the Internet Engineering Task Force
22 (IETF). It represents the consensus of the IETF community. It has
23 received public review and has been approved for publication by the
24 Internet Engineering Steering Group (IESG). Further information on
25 Internet Standards is available in Section 2 of RFC 5741.
26
27 Information about the current status of this document, any errata,
28 and how to provide feedback on it may be obtained at
29 http://www.rfc-editor.org/info/rfc6605.
30
31 Copyright Notice
32
33 Copyright (c) 2012 IETF Trust and the persons identified as the
34 document authors. All rights reserved.
35
36 This document is subject to BCP 78 and the IETF Trust's Legal
37 Provisions Relating to IETF Documents
38 (http://trustee.ietf.org/license-info) in effect on the date of
39 publication of this document. Please review these documents
40 carefully, as they describe your rights and restrictions with respect
41 to this document. Code Components extracted from this document must
42 include Simplified BSD License text as described in Section 4.e of
43 the Trust Legal Provisions and are provided without warranty as
44 described in the Simplified BSD License.
45
46
47
48
49
50
51
52 Hoffman & Wijngaards Standards Track [Page 1]
53 RFC 6605 ECDSA for DNSSEC April 2012
54
55
56 1. Introduction
57
58 DNSSEC, which is broadly defined in RFCs 4033, 4034, and 4035
59 ([RFC4033], [RFC4034], and [RFC4035]), uses cryptographic keys and
60 digital signatures to provide authentication of DNS data. Currently,
61 the most popular signature algorithm is RSA with SHA-1, using keys
62 that are 1024 or 2048 bits long.
63
64 This document defines the DNSKEY and RRSIG resource records (RRs) of
65 two new signing algorithms: ECDSA (Elliptic Curve DSA) with curve
66 P-256 and SHA-256, and ECDSA with curve P-384 and SHA-384. (A
67 description of ECDSA can be found in [FIPS-186-3].) This document
68 also defines the DS RR for the SHA-384 one-way hash algorithm; the
69 associated DS RR for SHA-256 is already defined in RFC 4509
70 [RFC4509]. [RFC6090] provides a good introduction to implementing
71 ECDSA.
72
73 Current estimates are that ECDSA with curve P-256 has an approximate
74 equivalent strength to RSA with 3072-bit keys. Using ECDSA with
75 curve P-256 in DNSSEC has some advantages and disadvantages relative
76 to using RSA with SHA-256 and with 3072-bit keys. ECDSA keys are
77 much shorter than RSA keys; at this size, the difference is 256
78 versus 3072 bits. Similarly, ECDSA signatures are much shorter than
79 RSA signatures. This is relevant because DNSSEC stores and transmits
80 both keys and signatures.
81
82 In the two signing algorithms defined in this document, the size of
83 the key for the elliptic curve is matched with the size of the output
84 of the hash algorithm. This design is based on the widespread belief
85 that the equivalent strength of P-256 and P-384 is half the length of
86 the key, and also that the equivalent strength of SHA-256 and SHA-384
87 is half the length of the key. Using matched strengths prevents an
88 attacker from choosing the weaker half of a signature algorithm. For
89 example, in a signature that uses RSA with 2048-bit keys and SHA-256,
90 the signing portion is significantly weaker than the hash portion,
91 whereas the two algorithms here are balanced.
92
93 Signing with ECDSA is significantly faster than with RSA (over 20
94 times in some implementations). However, validating RSA signatures
95 is significantly faster than validating ECDSA signatures (about 5
96 times faster in some implementations).
97
98 Some of the material in this document is copied liberally from RFC
99 6460 [RFC6460].
100
101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
103 document are to be interpreted as described in RFC 2119 [RFC2119].
104
105
106
107 Hoffman & Wijngaards Standards Track [Page 2]
108 RFC 6605 ECDSA for DNSSEC April 2012
109
110
111 2. SHA-384 DS Records
112
113 SHA-384 is defined in FIPS 180-3 [FIPS-180-3] and RFC 6234 [RFC6234],
114 and is similar to SHA-256 in many ways. The implementation of SHA-
115 384 in DNSSEC follows the implementation of SHA-256 as specified in
116 RFC 4509 except that the underlying algorithm is SHA-384, the digest
117 value is 48 bytes long, and the digest type code is 4.
118
119 3. ECDSA Parameters
120
121 Verifying ECDSA signatures requires agreement between the signer and
122 the verifier of the parameters used. FIPS 186-3 [FIPS-186-3] lists
123 some NIST-recommended elliptic curves. (Other documents give more
124 detail on ECDSA than is given in FIPS 186-3.) These are the same
125 curves listed in RFC 5114 [RFC5114]. The curves used in this
126 document are:
127
128 FIPS 186-3 RFC 5114
129 ------------------------------------------------------------------
130 P-256 (Section D.1.2.3) 256-bit Random ECP Group (Section 2.6)
131 P-384 (Section D.1.2.4) 384-bit Random ECP Group (Section 2.7)
132
133 4. DNSKEY and RRSIG Resource Records for ECDSA
134
135 ECDSA public keys consist of a single value, called "Q" in FIPS
136 186-3. In DNSSEC keys, Q is a simple bit string that represents the
137 uncompressed form of a curve point, "x | y".
138
139 The ECDSA signature is the combination of two non-negative integers,
140 called "r" and "s" in FIPS 186-3. The two integers, each of which is
141 formatted as a simple octet string, are combined into a single longer
142 octet string for DNSSEC as the concatenation "r | s". (Conversion of
143 the integers to bit strings is described in Section C.2 of FIPS
144 186-3.) For P-256, each integer MUST be encoded as 32 octets; for
145 P-384, each integer MUST be encoded as 48 octets.
146
147 The algorithm numbers associated with the DNSKEY and RRSIG resource
148 records are fully defined in the IANA Considerations section. They
149 are:
150
151 o DNSKEY and RRSIG RRs signifying ECDSA with the P-256 curve and
152 SHA-256 use the algorithm number 13.
153
154 o DNSKEY and RRSIG RRs signifying ECDSA with the P-384 curve and
155 SHA-384 use the algorithm number 14.
156
157
158
159
160
161
162 Hoffman & Wijngaards Standards Track [Page 3]
163 RFC 6605 ECDSA for DNSSEC April 2012
164
165
166 Conformant implementations that create records to be put into the DNS
167 MUST implement signing and verification for both of the above
168 algorithms. Conformant DNSSEC verifiers MUST implement verification
169 for both of the above algorithms.
170
171 5. Support for NSEC3 Denial of Existence
172
173 RFC 5155 [RFC5155] defines new algorithm identifiers for existing
174 signing algorithms to indicate that zones signed with these algorithm
175 identifiers can use NSEC3 as well as NSEC records to provide denial
176 of existence. That mechanism was chosen to protect implementations
177 predating RFC 5155 from encountering resource records they could not
178 know about. This document does not define such algorithm aliases.
179
180 A DNSSEC validator that implements the signing algorithms defined in
181 this document MUST be able to validate negative answers in the form
182 of both NSEC and NSEC3 with hash algorithm 1, as defined in RFC 5155.
183 An authoritative server that does not implement NSEC3 MAY still serve
184 zones that use the signing algorithms defined in this document with
185 NSEC denial of existence.
186
187 6. Examples
188
189 The following are some examples of ECDSA keys and signatures in DNS
190 format.
191
192 6.1. P-256 Example
193
194 Private-key-format: v1.2
195 Algorithm: 13 (ECDSAP256SHA256)
196 PrivateKey: GU6SnQ/Ou+xC5RumuIUIuJZteXT2z0O/ok1s38Et6mQ=
197
198 example.net. 3600 IN DNSKEY 257 3 13 (
199 GojIhhXUN/u4v54ZQqGSnyhWJwaubCvTmeexv7bR6edb
200 krSqQpF64cYbcB7wNcP+e+MAnLr+Wi9xMWyQLc8NAA== )
201
202 example.net. 3600 IN DS 55648 13 2 (
203 b4c8c1fe2e7477127b27115656ad6256f424625bf5c1
204 e2770ce6d6e37df61d17 )
205
206 www.example.net. 3600 IN A 192.0.2.1
207 www.example.net. 3600 IN RRSIG A 13 3 3600 (
208 20100909100439 20100812100439 55648 example.net.
209 qx6wLYqmh+l9oCKTN6qIc+bw6ya+KJ8oMz0YP107epXA
210 yGmt+3SNruPFKG7tZoLBLlUzGGus7ZwmwWep666VCw== )
211
212
213
214
215
216
217 Hoffman & Wijngaards Standards Track [Page 4]
218 RFC 6605 ECDSA for DNSSEC April 2012
219
220
221 6.2. P-384 Example
222
223 Private-key-format: v1.2
224 Algorithm: 14 (ECDSAP384SHA384)
225 PrivateKey: WURgWHCcYIYUPWgeLmiPY2DJJk02vgrmTfitxgqcL4vw
226 W7BOrbawVmVe0d9V94SR
227
228 example.net. 3600 IN DNSKEY 257 3 14 (
229 xKYaNhWdGOfJ+nPrL8/arkwf2EY3MDJ+SErKivBVSum1
230 w/egsXvSADtNJhyem5RCOpgQ6K8X1DRSEkrbYQ+OB+v8
231 /uX45NBwY8rp65F6Glur8I/mlVNgF6W/qTI37m40 )
232
233 example.net. 3600 IN DS 10771 14 4 (
234 72d7b62976ce06438e9c0bf319013cf801f09ecc84b8
235 d7e9495f27e305c6a9b0563a9b5f4d288405c3008a94
236 6df983d6 )
237
238 www.example.net. 3600 IN A 192.0.2.1
239 www.example.net. 3600 IN RRSIG A 14 3 3600 (
240 20100909102025 20100812102025 10771 example.net.
241 /L5hDKIvGDyI1fcARX3z65qrmPsVz73QD1Mr5CEqOiLP
242 95hxQouuroGCeZOvzFaxsT8Glr74hbavRKayJNuydCuz
243 WTSSPdz7wnqXL5bdcJzusdnI0RSMROxxwGipWcJm )
244
245
246
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 & Wijngaards Standards Track [Page 5]
273 RFC 6605 ECDSA for DNSSEC April 2012
274
275
276 7. IANA Considerations
277
278 This document updates the IANA registry for digest types in DS
279 records, currently called "Delegation Signer (DS) Resource Record
280 (RR) Type Digest Algorithms". The following entry has been added:
281
282 Value 4
283 Digest Type SHA-384
284 Status OPTIONAL
285
286 This document updates the IANA registry "Domain Name System Security
287 (DNSSEC) Algorithm Numbers". The following two entries have been
288 added to the registry:
289
290 Number 13
291 Description ECDSA Curve P-256 with SHA-256
292 Mnemonic ECDSAP256SHA256
293 Zone Signing Y
294 Trans. Sec. *
295 Reference This document
296
297 Number 14
298 Description ECDSA Curve P-384 with SHA-384
299 Mnemonic ECDSAP384SHA384
300 Zone Signing Y
301 Trans. Sec. *
302 Reference This document
303
304 * There has been no determination of standardization of the
305 use of this algorithm with Transaction Security.
306
307 8. Security Considerations
308
309 The cryptographic work factor of ECDSA with curve P-256 or P-384 is
310 generally considered to be equivalent to half the size of the key, or
311 128 bits and 192 bits, respectively. Such an assessment could, of
312 course, change in the future if new attacks that work better than the
313 ones known today are found.
314
315 The security considerations listed in RFC 4509 apply here as well.
316
317
318
319
320
321
322
323
324
325
326
327 Hoffman & Wijngaards Standards Track [Page 6]
328 RFC 6605 ECDSA for DNSSEC April 2012
329
330
331 9. References
332
333 9.1. Normative References
334
335 [FIPS-180-3] National Institute of Standards and Technology, U.S.
336 Department of Commerce, "Secure Hash Standard (SHS)",
337 FIPS 180-3, October 2008.
338
339 [FIPS-186-3] National Institute of Standards and Technology, U.S.
340 Department of Commerce, "Digital Signature Standard",
341 FIPS 186-3, June 2009.
342
343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
344 Requirement Levels", BCP 14, RFC 2119, March 1997.
345
346 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
347 Rose, "DNS Security Introduction and Requirements",
348 RFC 4033, March 2005.
349
350 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
351 Rose, "Resource Records for the DNS Security
352 Extensions", RFC 4034, March 2005.
353
354 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
355 Rose, "Protocol Modifications for the DNS Security
356 Extensions", RFC 4035, March 2005.
357
358 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation
359 Signer (DS) Resource Records (RRs)", RFC 4509,
360 May 2006.
361
362 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman
363 Groups for Use with IETF Standards", RFC 5114,
364 January 2008.
365
366 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
367 Security (DNSSEC) Hashed Authenticated Denial of
368 Existence", RFC 5155, March 2008.
369
370 9.2. Informative References
371
372 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental
373 Elliptic Curve Cryptography Algorithms", RFC 6090,
374 February 2011.
375
376 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash
377 Algorithms (SHA and SHA-based HMAC and HKDF)", RFC
378 6234, May 2011.
379
380
381
382 Hoffman & Wijngaards Standards Track [Page 7]
383 RFC 6605 ECDSA for DNSSEC April 2012
384
385
386 [RFC6460] Salter, M. and R. Housley, "Suite B Profile for
387 Transport Layer Security (TLS)", RFC 6460,
388 January 2012.
389
390 Authors' Addresses
391
392 Paul Hoffman
393 VPN Consortium
394
395 EMail: paul.hoffman@vpnc.org
396
397
398 Wouter C.A. Wijngaards
399 NLnet Labs
400
401 EMail: wouter@nlnetlabs.nl
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437 Hoffman & Wijngaards Standards Track [Page 8]
438
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). Compliance is conditional on the OpenSSL library being linked against a supporting ECDSA.