idnits 2.17.1 draft-hoffman-dnssec-ecdsa-03.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 12, 2010) is 4999 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4634 (Obsoleted by RFC 6234) -- Obsolete informational reference (is this intentional?): RFC 5430 (Obsoleted by RFC 6460) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 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: Informational W. Wijngaards 5 Expires: February 13, 2011 NLnet Labs 6 August 12, 2010 8 Elliptic Curve DSA for DNSSEC 9 draft-hoffman-dnssec-ecdsa-03 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 February 13, 2011. 34 Copyright Notice 36 Copyright (c) 2010 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 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 1. Introduction 63 DNSSEC, which is broadly defined in RFCs 4033, 4034, and 4035 64 ([RFC4033], [RFC4034], and [RFC4035]), uses cryptographic keys and 65 digital signatures to provide authentication of DNS data. Currently, 66 the most popular signature algorithm is RSA with SHA-1, using keys 67 1024 or 2048 bits long. 69 This document defines the DNSKEY and RRSIG resource records (RRs) of 70 two new signing algorithms: ECDSA with curve P-256 and SHA-256, and 71 ECDSA with curve P-384 and SHA-384. It also defines the DS RR for 72 the SHA-384 one-way hash algorithm; the associated DS RR for SHA-256 73 is already defined in RFC 4509 [RFC4509]. 75 Current estimates are that ECDSA with curve P-256 has an approximate 76 equivalent strength to RSA with 3072-bit keys. Using ECDSA with 77 curve P-256 in DNSSEC has some advantages and disadvantages relative 78 to using RSA with SHA-256 and with 3072-bit keys. ECDSA keys are 79 much shorter than RSA keys; at this size, the difference is 256 80 versus 3072 bits. Similarly, ECDSA signatures are much shorter than 81 RSA signatures. This is relevant because DNSSEC stores and transmits 82 both keys and signatures. 84 Signing with ECDSA is significantly faster than with RSA (over 20 85 times in some implementations). However, validating RSA signatures 86 is significantly faster than validating ECDSA signatures (about 5 87 times faster in some implementations). 89 Some of the material in this document is copied liberally from RFC 90 5430 [RFC5430]. 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 2. SHA-384 DS Records 98 SHA-384 is defined in FIPS 180-3 [FIPS-180-3] and RFC 4634 [RFC4634], 99 and is similar to SHA-256 in many ways. The implementation of SHA- 100 384 in DNSSEC follows the implementation of SHA-256 as specified in 101 RFC 4509 except that the underlying algorithm is SHA-384, the digest 102 value is 48 bytes long, and the digest type code is {TBA-1}. 104 3. ECDSA Parameters 106 Verifying ECDSA signatures requires agreement between the signer and 107 the verifier of the parameters used. FIPS 186-3 [FIPS-186-3] lists 108 some NIST-recommended elliptic curves. These are the same curves as 109 listed in RFC 5114 [RFC5114]. The curves used in this document are: 111 FIPS 186-3 RFC 5114 112 ------------------------------------------------------------------ 113 P-256 (Section D.1.2.3) 256-bit Random ECP Group (Section 2.6) 114 P-384 (Section D.1.2.4) 384-bit Random ECP Group (Section 2.7) 116 4. DNSKEY and RRSIG Resource Records for ECDSA 118 ECDSA public keys consist of a single value, called "Q" in FIPS 119 186-3. In DNSSEC keys, Q is a simple bit string that represents the 120 uncompressed form of a curve point, "x | y". 122 The ECDSA signature is the combination of two non-negative integers, 123 called "r" and "s" in FIPS 186-3. The two integers, each of which is 124 formatted as a simple bit string, are combined into a single longer 125 bit string for DNSSEC as the concatenation "r | s". 127 The algorithm numbers associated with the DNSKEY and RRSIG resource 128 records are fully defined in the IANA Considerations section. They 129 are: 131 o DNSKEY and RRSIG RRs signifying ECDSA with the P-256 curve and 132 SHA-256 use the algorithm number {TBA-2}. 134 o DNSKEY and RRSIG RRs signifying ECDSA with the P-384 curve and 135 SHA-384 use the algorithm number {TBA-3}. 137 Conformant implementations MUST support signing and/or validation of 138 signatures with both ECDSA with the P-256 curve and SHA-256, and with 139 ECDSA with the P-384 curve and SHA-384. 141 5. Support for NSEC3 Denial of Existence 143 RFC 5155 [RFC5155] defines new algorithm identifiers for existing 144 signing algorithms, to indicate that zones signed with these 145 algorithm identifiers can use NSEC3 as well as NSEC records to 146 provide denial of existence. That mechanism was chosen to protect 147 implementations predating RFC 5155 from encountering resource records 148 they could not know about. This document does not define such 149 algorithm aliases. 151 A DNSSEC validator that implements the signing algorithms defined in 152 this document MUST be able to validate negative answers in the form 153 of both NSEC and NSEC3 with hash algorithm 1, as defined in RFC 5155. 154 An authoritative server that does not implement NSEC3 MAY still serve 155 zones that use the signing algorithms defined in this document with 156 NSEC denial of existence. 158 6. Examples 160 The following are some examples of ECDSA keys and signatures in DNS 161 format. 163 [[ IMPORTANT NOTE: This section is to be used for testing only. This 164 document has not been approved as an RFC, so the algorithm codes MUST 165 NOT be used on the Internet, only in test environments. The examples 166 use {TBA-1}: 4, {TBA-2}: 13, {TBA-3}: 14. ]] 168 6.1. P-256 Example 170 Private-key-format: v1.2 171 Algorithm: 13 (ECDSAP256SHA256) 172 PrivateKey: GU6SnQ/Ou+xC5RumuIUIuJZteXT2z0O/ok1s38Et6mQ= 174 example.net. 3600 IN DNSKEY 257 3 13 ( 175 GojIhhXUN/u4v54ZQqGSnyhWJwaubCvTmeexv7bR6edb 176 krSqQpF64cYbcB7wNcP+e+MAnLr+Wi9xMWyQLc8NAA== ) 178 example.net. 3600 IN DS 55648 13 2 ( 179 b4c8c1fe2e7477127b27115656ad6256f424625bf5c1 180 e2770ce6d6e37df61d17 ) 182 www.example.net. 3600 IN A 192.0.2.1 183 www.example.net. 3600 IN RRSIG A 13 3 3600 ( 184 20100909100439 20100812100439 55648 example.net. 185 qx6wLYqmh+l9oCKTN6qIc+bw6ya+KJ8oMz0YP107epXA 186 yGmt+3SNruPFKG7tZoLBLlUzGGus7ZwmwWep666VCw== ) 188 6.2. P-384 Example 190 Private-key-format: v1.2 191 Algorithm: 14 (ECDSAP384SHA384) 192 PrivateKey: WURgWHCcYIYUPWgeLmiPY2DJJk02vgrmTfitxgqcL4vw 193 W7BOrbawVmVe0d9V94SR 195 example.net. 3600 IN DNSKEY 257 3 14 ( 196 xKYaNhWdGOfJ+nPrL8/arkwf2EY3MDJ+SErKivBVSum1 197 w/egsXvSADtNJhyem5RCOpgQ6K8X1DRSEkrbYQ+OB+v8 198 /uX45NBwY8rp65F6Glur8I/mlVNgF6W/qTI37m40 ) 200 example.net. 3600 IN DS 10771 14 4 ( 201 72d7b62976ce06438e9c0bf319013cf801f09ecc84b8 202 d7e9495f27e305c6a9b0563a9b5f4d288405c3008a94 203 6df983d6 ) 205 www.example.net. 3600 IN A 192.0.2.1 206 www.example.net. 3600 IN RRSIG A 14 3 3600 ( 207 20100909102025 20100812102025 10771 example.net. 208 /L5hDKIvGDyI1fcARX3z65qrmPsVz73QD1Mr5CEqOiLP 209 95hxQouuroGCeZOvzFaxsT8Glr74hbavRKayJNuydCuz 210 WTSSPdz7wnqXL5bdcJzusdnI0RSMROxxwGipWcJm ) 212 7. IANA Considerations 214 This document updates the IANA registry for digest types in DS 215 records, currently called "Delegation Signer Resource Record, Digest 216 Algorithms". The following entry is added: 218 Value {TBA-1} 219 Digest Type SHA-384 220 Status OPTIONAL 222 This document updates the IANA registry "Domain Name System Security 223 (DNSSEC) Algorithm Numbers". The following two entries are added to 224 the registry: 226 Number {TBA-2} 227 Description ECDSA Curve P-256 with SHA-256 228 Mnemonic ECDSAP256SHA256 229 Zone Signing Y 230 Trans. Sec. * 231 Reference This document 233 Number {TBA-3} 234 Description ECDSA Curve P-384 with SHA-384 235 Mnemonic ECDSAP384SHA384 236 Zone Signing Y 237 Trans. Sec. * 238 Reference This document 240 * There has been no determination of standardization of the 241 use of this algorithm with Transaction Security. 243 8. Security Considerations 245 The cryptographic strength of ECDSA with curve P-256 or P-384 is 246 generally considered to be equivalent to half the size of the key, or 247 128 bits and 192 bits, respectively. Such an assessment could, of 248 course, change in the future if new attacks that work better than the 249 ones known today are found. 251 9. References 253 9.1. Normative References 255 [FIPS-180-3] 256 National Institute of Standards and Technology, U.S. 257 Department of Commerce, "Secure Hash Standard (SHS)", 258 FIPS 180-3, October 2008. 260 [FIPS-186-3] 261 National Institute of Standards and Technology, U.S. 262 Department of Commerce, "Digital Signature Standard", 263 FIPS 186-3, June 2009. 265 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 266 Requirement Levels", BCP 14, RFC 2119, March 1997. 268 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 269 Rose, "DNS Security Introduction and Requirements", 270 RFC 4033, March 2005. 272 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 273 Rose, "Resource Records for the DNS Security Extensions", 274 RFC 4034, March 2005. 276 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 277 Rose, "Protocol Modifications for the DNS Security 278 Extensions", RFC 4035, March 2005. 280 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 281 (DS) Resource Records (RRs)", RFC 4509, May 2006. 283 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 284 Groups for Use with IETF Standards", RFC 5114, 285 January 2008. 287 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 288 Security (DNSSEC) Hashed Authenticated Denial of 289 Existence", RFC 5155, March 2008. 291 9.2. Informative References 293 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 294 (SHA and HMAC-SHA)", RFC 4634, July 2006. 296 [RFC5430] Salter, M., Rescorla, E., and R. Housley, "Suite B Profile 297 for Transport Layer Security (TLS)", RFC 5430, March 2009. 299 Appendix A. Change History 301 This entire section should be removed before publication as an RFC. 303 A.1. Changes betweeen draft-hoffman-dnssec-ecdsa-00 and -01 305 Numerous editorial fixes from Alfred Hoenes. 307 In the IANA Considerations, used the same wording about TSIG as is 308 used in draft-ietf-dnsext-dnssec-rsasha256-14: "There has been no 309 determination of standardization of the use of this algorithm with 310 Transaction Security." 312 A.2. Changes betweeen draft-hoffman-dnssec-ecdsa-01 and -02 314 None; version bump. 316 A.3. Changes betweeen draft-hoffman-dnssec-ecdsa-02 and -03 318 Added Wouter Wijngaards as co-author. 320 Removed ECDSAP224SHA256 to simplify. 322 The DNSKEY is defined as being storted as "x | y". 324 Added examples. 326 Authors' Addresses 328 Paul Hoffman 329 VPN Consortium 331 Email: paul.hoffman@vpnc.org 333 Wouter Wijngaards 334 NLnet Labs 336 Email: wouter@nlnetlabs.nl