idnits 2.17.1 draft-hoffman-dnssec-ecdsa-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- No issues found here. 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 (January 25, 2010) is 5204 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 4634 (Obsoleted by RFC 6234) -- Obsolete informational reference (is this intentional?): RFC 5430 (Obsoleted by RFC 6460) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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 January 25, 2010 5 Expires: July 29, 2010 7 Elliptic Curve DSA for DNSSEC 8 draft-hoffman-dnssec-ecdsa-01 10 Abstract 12 This document describes how to specify Elliptic Curve DSA keys and 13 signatures in DNSSEC. It lists curves of different sizes, and uses 14 the SHA-2 family of hashes for signatures. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on July 29, 2010. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 1. Introduction 68 DNSSEC, which is broadly defined in RFCs 4033, 4034, and 4035 69 ([RFC4033], [RFC4034], and [RFC4035]), uses cryptographic keys and 70 digital signatures to provide authentication of DNS data. Currently, 71 the most popular signature algorithm is RSA with SHA-1, using keys 72 1024 or 2048 bits long. 74 This document defines the DNSKEY and RRSIG resource records (RRs) of 75 three new signing algorithms: ECDSA with curve P-224 and SHA-256, 76 ECDSA with curve P-256 and SHA-256, and ECDSA with curve P-384 and 77 SHA-384. It also defines the DS RR for the SHA-384 one-way hash 78 algorithm; the associated DS RR for SHA-256 is already defined in RFC 79 4509 [RFC4509]. 81 Current estimates are that ECDSA with curve P-256 has an approximate 82 equivalent strength to RSA with 3072-bit keys. Using ECDSA with 83 curve P-256 in DNSSEC has some advantages and disadvantages relative 84 to using RSA with SHA-256 and with 3072-bit keys. ECDSA keys are 85 much shorter than RSA keys; at this size, the difference is 256 86 versus 3072 bits. Similarly, ECDSA signatures are much shorter than 87 RSA signatures. This is relevant because DNSSEC stores and transmits 88 both keys and signatures. 90 Signing with ECDSA is significantly faster than with RSA (over 20 91 times in some implementations). However, validating RSA signatures 92 is significantly faster than validating ECDSA signatures (about 5 93 times faster in some implementations). 95 Some of the material in this document is copied liberally from RFC 96 5430 [RFC5430]. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 2. SHA-384 DS Records 104 SHA-384 is defined in FIPS 180-3 [FIPS-180-3] and RFC 4634 [RFC4634], 105 and is similar to SHA-256 in many ways. The implementation of SHA- 106 384 in DNSSEC follows the implementation of SHA-256 as specified in 107 RFC 4509 except that the underlying algorithm is SHA-384, the digest 108 value is 48 bytes long, and the digest type code is {TBA-1}. 110 3. ECDSA Parameters 112 Verifying ECDSA signatures requires agreement between the signer and 113 the verifier of the parameters used. FIPS 186-3 [FIPS-186-3] lists 114 some NIST-recommended elliptic curves. These are the same curves as 115 listed in RFC 5114 [RFC5114]. The curves used in this document are: 117 FIPS 186-3 RFC 5114 118 ------------------------------------------------------------------ 119 P-224 (Section D.1.2.2) 224-bit Random ECP Group (Section 2.5) 120 P-256 (Section D.1.2.3) 256-bit Random ECP Group (Section 2.6) 121 P-384 (Section D.1.2.4) 384-bit Random ECP Group (Section 2.7) 123 4. DNSKEY and RRSIG Resource Records for ECDSA 125 ECDSA public keys consist of a single value, called "Q" in FIPS 126 186-3. In DNSSEC keys, Q is a simple bit string that represents the 127 uncompressed form of a curve point. 129 The ECDSA signature is the combination of two non-negative integers, 130 called "r" and "s" in FIPS 186-3. The two integers, each of which is 131 formatted as a simple bit string, are combined into a single longer 132 bit string for DNSSEC as the concatenation "r | s". 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-224 curve and 139 SHA-256 use the algorithm number {TBA-2}. 141 o DNSKEY and RRSIG RRs signifying ECDSA with the P-256 curve and 142 SHA-256 use the algorithm number {TBA-3}. 144 o DNSKEY and RRSIG RRs signifying ECDSA with the P-384 curve and 145 SHA-384 use the algorithm number {TBA-4}. 147 Conformant implementations MUST support signing and/or validation of 148 signatures with both ECDSA with the P-256 curve and SHA-256, and with 149 ECDSA with the P-384 curve and SHA-384. (ECDSA with the P-224 curve 150 and SHA-256 is defined here for systems that want to have a strength 151 equivalence of RSA with 2048-bit keys, but is not required for 152 conformance.) 154 5. Support for NSEC3 Denial of Existence 156 RFC 5155 [RFC5155] defines new algorithm identifiers for existing 157 signing algorithms, to indicate that zones signed with these 158 algorithm identifiers can use NSEC3 as well as NSEC records to 159 provide denial of existence. That mechanism was chosen to protect 160 implementations predating RFC 5155 from encountering resource records 161 they could not know about. This document does not define such 162 algorithm aliases. 164 A DNSSEC validator that implements the signing algorithms defined in 165 this document MUST be able to validate negative answers in the form 166 of both NSEC and NSEC3 with hash algorithm 1, as defined in RFC 5155. 167 An authoritative server that does not implement NSEC3 MAY still serve 168 zones that use the signing algorithms defined in this document with 169 NSEC denial of existence. 171 6. Examples 173 [[ To be filled in later. ]] 175 7. IANA Considerations 177 This document updates the IANA registry for digest types in DS 178 records, currently called "Delegation Signer Resource Record, Digest 179 Algorithms". The following entry is added: 181 Value {TBA-1} 182 Digest Type SHA-384 183 Status OPTIONAL 185 This document updates the IANA registry "Domain Name System Security 186 (DNSSEC) Algorithm Numbers". The following three entries are added 187 to the registry: 189 Number {TBA-2} 190 Description ECDSA Curve P-224 with SHA-256 191 Mnemonic ECDSAP224SHA256 192 Zone Signing Y 193 Trans. Sec. * 194 Reference This document 196 Number {TBA-3} 197 Description ECDSA Curve P-256 with SHA-256 198 Mnemonic ECDSAP256SHA256 199 Zone Signing Y 200 Trans. Sec. * 201 Reference This document 203 Number {TBA-4} 204 Description ECDSA Curve P-384 with SHA-384 205 Mnemonic ECDSAP384SHA384 206 Zone Signing Y 207 Trans. Sec. * 208 Reference This document 210 * There has been no determination of standardization of the 211 use of this algorithm with Transaction Security. 213 8. Security Considerations 215 The cryptographic strength of ECDSA with curve P-224, P-256 or P-384 216 is generally considered to be equivalent to half the size of the key, 217 or 112 bits, 128 bits, and 192 bits, respectively. Such an 218 assessment could, of course, change in the future if new attacks that 219 work better than the ones known today are found. 221 9. References 223 9.1. Normative References 225 [FIPS-180-3] 226 National Institute of Standards and Technology, U.S. 227 Department of Commerce, "Secure Hash Standard (SHS)", 228 FIPS 180-3, October 2008. 230 [FIPS-186-3] 231 National Institute of Standards and Technology, U.S. 233 Department of Commerce, "Digital Signature Standard", 234 FIPS 186-3, June 2009. 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, March 1997. 239 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 240 Rose, "DNS Security Introduction and Requirements", 241 RFC 4033, March 2005. 243 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 244 Rose, "Resource Records for the DNS Security Extensions", 245 RFC 4034, March 2005. 247 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 248 Rose, "Protocol Modifications for the DNS Security 249 Extensions", RFC 4035, March 2005. 251 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 252 (DS) Resource Records (RRs)", RFC 4509, May 2006. 254 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 255 Groups for Use with IETF Standards", RFC 5114, 256 January 2008. 258 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 259 Security (DNSSEC) Hashed Authenticated Denial of 260 Existence", RFC 5155, March 2008. 262 9.2. Informative References 264 [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 265 (SHA and HMAC-SHA)", RFC 4634, July 2006. 267 [RFC5430] Salter, M., Rescorla, E., and R. Housley, "Suite B Profile 268 for Transport Layer Security (TLS)", RFC 5430, March 2009. 270 Appendix A. Change History 272 This entire section should be removed before publication as an RFC. 274 A.1. Changes betweeen draft-hoffman-dnssec-ecdsa-00 and -01 276 Numerous editorial fixes from Alfred Hoenes. 278 In the IANA Considerations, used the same wording about TSIG as is 279 used in draft-ietf-dnsext-dnssec-rsasha256-14: "There has been no 280 determination of standardization of the use of this algorithm with 281 Transaction Security." 283 Author's Address 285 Paul Hoffman 286 VPN Consortium 288 Email: paul.hoffman@vpnc.org