idnits 2.17.1 draft-ietf-dnsext-ecdsa-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 29, 2012) is 4402 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186-3' ** Downref: Normative reference to an Informational RFC: RFC 5114 -- Obsolete informational reference (is this intentional?): RFC 5430 (Obsoleted by RFC 6460) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft VPN Consortium 4 Intended status: Standards Track W. Wijngaards 5 Expires: September 1, 2012 NLnet Labs 6 February 29, 2012 8 Elliptic Curve DSA for DNSSEC 9 draft-ietf-dnsext-ecdsa-07 11 Abstract 13 This document describes how to specify Elliptic Curve DSA keys and 14 signatures in DNSSEC. It lists curves of different sizes, and uses 15 the SHA-2 family of hashes for signatures. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 1, 2012. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 DNSSEC, which is broadly defined in RFCs 4033, 4034, and 4035 52 ([RFC4033], [RFC4034], and [RFC4035]), uses cryptographic keys and 53 digital signatures to provide authentication of DNS data. Currently, 54 the most popular signature algorithm is RSA with SHA-1, using keys 55 1024 or 2048 bits long. 57 This document defines the DNSKEY and RRSIG resource records (RRs) of 58 two new signing algorithms: ECDSA (Elliptic Curve DSA) with curve 59 P-256 and SHA-256, and ECDSA with curve P-384 and SHA-384. (A 60 description of ECDSA can be found in [FIPS-186-3].) This document 61 also defines the DS RR for the SHA-384 one-way hash algorithm; the 62 associated DS RR for SHA-256 is already defined in RFC 4509 63 [RFC4509]. [RFC6090] provides a good introducition to implementing 64 ECDSA. 66 Current estimates are that ECDSA with curve P-256 has an approximate 67 equivalent strength to RSA with 3072-bit keys. Using ECDSA with 68 curve P-256 in DNSSEC has some advantages and disadvantages relative 69 to using RSA with SHA-256 and with 3072-bit keys. ECDSA keys are 70 much shorter than RSA keys; at this size, the difference is 256 71 versus 3072 bits. Similarly, ECDSA signatures are much shorter than 72 RSA signatures. This is relevant because DNSSEC stores and transmits 73 both keys and signatures. 75 In the two signing algorithms defined in this document, the size of 76 the key for the elliptic curve is matched with the size of the output 77 of the hash algorithm. This design is based on the widespread belief 78 that the equivalent strength of P-256 and P-384 is half the length of 79 the key, and also that the equivalent strength of SHA-256 and SHA-384 80 is half the length of the key. Using matched strengths prevents an 81 attacker from choosing the weaker half of a signature algorithm. For 82 example, in a signature that uses RSA with 2048-bit keys and SHA-256, 83 the signing portion is significantly weaker than the hash portion, 84 whereas the two algorithms here are balanced. 86 Signing with ECDSA is significantly faster than with RSA (over 20 87 times in some implementations). However, validating RSA signatures 88 is significantly faster than validating ECDSA signatures (about 5 89 times faster in some implementations). 91 Some of the material in this document is copied liberally from RFC 92 5430 [RFC5430]. 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 2. SHA-384 DS Records 100 SHA-384 is defined in FIPS 180-3 [FIPS-180-3] and RFC 6234 [RFC6234], 101 and is similar to SHA-256 in many ways. The implementation of SHA- 102 384 in DNSSEC follows the implementation of SHA-256 as specified in 103 RFC 4509 except that the underlying algorithm is SHA-384, the digest 104 value is 48 bytes long, and the digest type code is {TBA-1}. 106 3. ECDSA Parameters 108 Verifying ECDSA signatures requires agreement between the signer and 109 the verifier of the parameters used. FIPS 186-3 [FIPS-186-3] lists 110 some NIST-recommended elliptic curves. (Other documents give more 111 detail on ECDSA than is given in FIPS 186-3.) These are the same 112 curves as listed in RFC 5114 [RFC5114]. The curves used in this 113 document are: 115 FIPS 186-3 RFC 5114 116 ------------------------------------------------------------------ 117 P-256 (Section D.1.2.3) 256-bit Random ECP Group (Section 2.6) 118 P-384 (Section D.1.2.4) 384-bit Random ECP Group (Section 2.7) 120 4. DNSKEY and RRSIG Resource Records for ECDSA 122 ECDSA public keys consist of a single value, called "Q" in FIPS 123 186-3. In DNSSEC keys, Q is a simple bit string that represents the 124 uncompressed form of a curve point, "x | y". 126 The ECDSA signature is the combination of two non-negative integers, 127 called "r" and "s" in FIPS 186-3. The two integers, each of which is 128 formatted as a simple octet string, are combined into a single longer 129 octet string for DNSSEC as the concatenation "r | s". (Conversion of 130 the integers to bit strings is described in Section C.2 of FIPS 131 186-3.) For P-256, each integer MUST be encoded as 32 octets; for 132 P-384, each integer MUST each be encoded as 48 octets. 134 The algorithm numbers associated with the DNSKEY and RRSIG resource 135 records are fully defined in the IANA Considerations section. They 136 are: 138 o DNSKEY and RRSIG RRs signifying ECDSA with the P-256 curve and 139 SHA-256 use the algorithm number {TBA-2}. 141 o DNSKEY and RRSIG RRs signifying ECDSA with the P-384 curve and 142 SHA-384 use the algorithm number {TBA-3}. 144 Conformant implementations that create records to be put into the DNS 145 MUST implement signing and verification for both of the above 146 algorithms. Conformant DNSSEC verifiers MUST implement verification 147 for both of the above algorithms. 149 5. Support for NSEC3 Denial of Existence 151 RFC 5155 [RFC5155] defines new algorithm identifiers for existing 152 signing algorithms, to indicate that zones signed with these 153 algorithm identifiers can use NSEC3 as well as NSEC records to 154 provide denial of existence. That mechanism was chosen to protect 155 implementations predating RFC 5155 from encountering resource records 156 they could not know about. This document does not define such 157 algorithm aliases. 159 A DNSSEC validator that implements the signing algorithms defined in 160 this document MUST be able to validate negative answers in the form 161 of both NSEC and NSEC3 with hash algorithm 1, as defined in RFC 5155. 162 An authoritative server that does not implement NSEC3 MAY still serve 163 zones that use the signing algorithms defined in this document with 164 NSEC denial of existence. 166 6. Examples 168 The following are some examples of ECDSA keys and signatures in DNS 169 format. 171 [[ IMPORTANT NOTE: This section is to be used for testing only until 172 IANA allocates code points. The examples use {TBA-1}: 4, {TBA-2}: 173 13, {TBA-3}: 14. IANA is requested to allocate these code points to 174 their respective registries in the IANA Considerations section. ]] 176 6.1. P-256 Example 178 Private-key-format: v1.2 179 Algorithm: 13 (ECDSAP256SHA256) 180 PrivateKey: GU6SnQ/Ou+xC5RumuIUIuJZteXT2z0O/ok1s38Et6mQ= 182 example.net. 3600 IN DNSKEY 257 3 13 ( 183 GojIhhXUN/u4v54ZQqGSnyhWJwaubCvTmeexv7bR6edb 184 krSqQpF64cYbcB7wNcP+e+MAnLr+Wi9xMWyQLc8NAA== ) 186 example.net. 3600 IN DS 55648 13 2 ( 187 b4c8c1fe2e7477127b27115656ad6256f424625bf5c1 188 e2770ce6d6e37df61d17 ) 190 www.example.net. 3600 IN A 192.0.2.1 191 www.example.net. 3600 IN RRSIG A 13 3 3600 ( 192 20100909100439 20100812100439 55648 example.net. 193 qx6wLYqmh+l9oCKTN6qIc+bw6ya+KJ8oMz0YP107epXA 194 yGmt+3SNruPFKG7tZoLBLlUzGGus7ZwmwWep666VCw== ) 196 6.2. P-384 Example 198 Private-key-format: v1.2 199 Algorithm: 14 (ECDSAP384SHA384) 200 PrivateKey: WURgWHCcYIYUPWgeLmiPY2DJJk02vgrmTfitxgqcL4vw 201 W7BOrbawVmVe0d9V94SR 203 example.net. 3600 IN DNSKEY 257 3 14 ( 204 xKYaNhWdGOfJ+nPrL8/arkwf2EY3MDJ+SErKivBVSum1 205 w/egsXvSADtNJhyem5RCOpgQ6K8X1DRSEkrbYQ+OB+v8 206 /uX45NBwY8rp65F6Glur8I/mlVNgF6W/qTI37m40 ) 208 example.net. 3600 IN DS 10771 14 4 ( 209 72d7b62976ce06438e9c0bf319013cf801f09ecc84b8 210 d7e9495f27e305c6a9b0563a9b5f4d288405c3008a94 211 6df983d6 ) 213 www.example.net. 3600 IN A 192.0.2.1 214 www.example.net. 3600 IN RRSIG A 14 3 3600 ( 215 20100909102025 20100812102025 10771 example.net. 216 /L5hDKIvGDyI1fcARX3z65qrmPsVz73QD1Mr5CEqOiLP 217 95hxQouuroGCeZOvzFaxsT8Glr74hbavRKayJNuydCuz 218 WTSSPdz7wnqXL5bdcJzusdnI0RSMROxxwGipWcJm ) 220 7. IANA Considerations 222 This document updates the IANA registry for digest types in DS 223 records, currently called "Delegation Signer Resource Record, Digest 224 Algorithms". The following entry is added: 226 Value {TBA-1} (Suggested value: 4) 227 Digest Type SHA-384 228 Status OPTIONAL 230 This document updates the IANA registry "Domain Name System Security 231 (DNSSEC) Algorithm Numbers". The following two entries are added to 232 the registry: 234 Number {TBA-2} (Suggested value: 13) 235 Description ECDSA Curve P-256 with SHA-256 236 Mnemonic ECDSAP256SHA256 237 Zone Signing Y 238 Trans. Sec. * 239 Reference This document 241 Number {TBA-3} (Suggested value: 14) 242 Description ECDSA Curve P-384 with SHA-384 243 Mnemonic ECDSAP384SHA384 244 Zone Signing Y 245 Trans. Sec. * 246 Reference This document 248 * There has been no determination of standardization of the 249 use of this algorithm with Transaction Security. 251 8. Security Considerations 253 The cryptographic work factor of ECDSA with curve P-256 or P-384 is 254 generally considered to be equivalent to half the size of the key, or 255 128 bits and 192 bits, respectively. Such an assessment could, of 256 course, change in the future if new attacks that work better than the 257 ones known today are found. 259 The security considerations listed in RFC 4509 apply here as well. 261 9. References 262 9.1. Normative References 264 [FIPS-180-3] 265 National Institute of Standards and Technology, U.S. 266 Department of Commerce, "Secure Hash Standard (SHS)", 267 FIPS 180-3, October 2008. 269 [FIPS-186-3] 270 National Institute of Standards and Technology, U.S. 271 Department of Commerce, "Digital Signature Standard", 272 FIPS 186-3, June 2009. 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, March 1997. 277 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 278 Rose, "DNS Security Introduction and Requirements", 279 RFC 4033, March 2005. 281 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 282 Rose, "Resource Records for the DNS Security Extensions", 283 RFC 4034, March 2005. 285 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 286 Rose, "Protocol Modifications for the DNS Security 287 Extensions", RFC 4035, March 2005. 289 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 290 (DS) Resource Records (RRs)", RFC 4509, May 2006. 292 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 293 Groups for Use with IETF Standards", RFC 5114, 294 January 2008. 296 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 297 Security (DNSSEC) Hashed Authenticated Denial of 298 Existence", RFC 5155, March 2008. 300 9.2. Informative References 302 [RFC5430] Salter, M., Rescorla, E., and R. Housley, "Suite B Profile 303 for Transport Layer Security (TLS)", RFC 5430, March 2009. 305 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 306 Curve Cryptography Algorithms", RFC 6090, February 2011. 308 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 309 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 311 Authors' Addresses 313 Paul Hoffman 314 VPN Consortium 316 Email: paul.hoffman@vpnc.org 318 Wouter Wijngaards 319 NLnet Labs 321 Email: wouter@nlnetlabs.nl