idnits 2.17.1 draft-ietf-curdle-dnskey-ed25519-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 16, 2016) is 2963 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-irtf-cfrg-eddsa-02 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-eddsa (ref. 'I-D.irtf-cfrg-eddsa') ** Downref: Normative reference to an Informational RFC: RFC 7748 -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force O. Sury 3 Internet-Draft CZ.NIC 4 Intended status: Standards Track R. Edmonds 5 Expires: August 19, 2016 Farsight Security, Inc. 6 February 16, 2016 8 Ed25519 for DNSSEC 9 draft-ietf-curdle-dnskey-ed25519-01 11 Abstract 13 This document describes how to specify Ed25519 keys and signatures in 14 DNS Security (DNSSEC). It uses the Edwards-curve Digital Security 15 Algorithm (EdDSA) with the Ed25519 parameter choice. 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 August 19, 2016. 34 Copyright Notice 36 Copyright (c) 2016 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 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 53 3. DNSKEY and RRSIG Resource Records for Ed25519 . . . . . . . . 3 54 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 61 9.2. Informative References . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Introduction 66 DNSSEC, which is broadly defined in [RFC4033], [RFC4034], and 67 [RFC4035], uses cryptographic keys and digital signatures to provide 68 authentication of DNS data. Currently, the most popular signature 69 algorithm in use is RSA. [RFC5933] and [RFC6605] later defined the 70 use of GOST and NIST specified elliptic curve cryptography in DNSSEC. 72 This document defines the use of DNSSEC's DS, DNSKEY, and RRSIG 73 resource records (RRs) with a new signing algorithm, Edwards-curve 74 Digital Signature Algorithm (EdDSA) with the Ed25519 parameter 75 choice. A more thorough description of EdDSA and Ed25519 can be 76 found in [I-D.irtf-cfrg-eddsa]. 78 Concerns about the real-world security of elliptic curve cryptography 79 have emerged since ECDSA was standardized for DNSSEC. The only two 80 curves standardized for use with ECDSA in DNSSEC, NIST P-256 and NIST 81 P-384, fail several of the [SafeCurves] security criteria and are 82 considered "unsafe". This document adds an additional elliptic curve 83 algorithm and parameter choice to DNSSEC, allowing additional 84 flexibility. 86 There are three main advantages of the EdDSA algorithm: It does not 87 require the use of a unique random number for each signature, there 88 are no padding or truncation issues as with ECDSA, and it is more 89 resilient to side-channel attacks. 91 Ed25519 has a 128-bit security target, which is considered to be 92 equivalent in strength to RSA with ~3000-bit keys. Ed25519 public 93 keys are 256 bits (32 bytes) long while signatures are 512 bits (64 94 bytes) long. 96 The usage of elliptic curve cryptography in DNSSEC has advantages and 97 disadvantages relative to RSA as already described in [RFC6605]. 98 Even when compared to the use of RSA at reduced relative strengths 99 (for instance, 1024- or 2048-bit RSA), Ed25519 still requires 100 substantially smaller keys and signatures. The authors of the study 101 Making the Case for Elliptic Curves in DNSSEC [ECCSIZE] came to the 102 conclusion that using elliptic curve cryptography rather than RSA in 103 DNSSEC can effectively prevent fragmentation of DNSSEC responses as 104 well as significantly reduce the amplification attack potential in 105 DNSSEC. 107 Signing with Ed25519 is significantly faster than signing with either 108 equivalently strong RSA or the two existing curves standardized for 109 use with the ECDSA algorithm in DNSSEC, while the validation of RSA 110 signatures is still significantly faster than the validation of 111 Ed25519 signatures. However, the authors of the TBD [ECCSPEED] study 112 came to the conclusion that even if the deployment of elliptic curve 113 cryptography in DNSSEC grows to cover 100% of the name space, a 114 resolver will still be able to perform validation using a single CPU 115 core. 117 2. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 3. DNSKEY and RRSIG Resource Records for Ed25519 125 An Ed25519 public key consists of a 32-byte value, which is encoded 126 into the Public Key field of a DNSKEY resource record as a simple bit 127 string. The generation of a public key is defined in Chapter 5.1.5 128 in [I-D.irtf-cfrg-eddsa]. 130 An Ed25519 signature consists of a 64-byte value, which is encoded 131 into the Signature field of an RRSIG resource record as a simple bit 132 string. The Ed25519 signature algorithm is described in Chapter 133 5.1.6 in [I-D.irtf-cfrg-eddsa]. 135 The algorithm number associated with the use of Ed25519 in DS, DNSKEY 136 and RRSIG resource records is TBD. This registration is fully 137 defined in the IANA Considerations section. 139 4. Examples 140 This section needs an update after the algorithm for Ed25519 is 141 assigned. 143 Private-key-format: v1.2 144 Algorithm: TBD (ED25519) 145 PrivateKey: ODIyNjAzODQ2MjgwODAxMjI2NDUxOTAyMDQxNDIyNjI= 146 # corresponding to 82260384628080122645190204142262 INT 148 example.com. 3600 IN DNSKEY 257 3 TBD ( 149 l02Woi0iS8Aa25FQkUd9RMzZHJpBoRQwAQEX1SxZJA4= ) 151 example.com. 3600 IN DS 3613 TBD 2 ( 152 3aa5ab37efce57f737fc1627013fee07bdf241bd10f3 153 b1964ab55c78e79a304b ) 155 www.example.com. 3600 IN A 192.0.2.1 156 www.example.com. 3600 IN RRSIG A TBD 3 3600 ( 157 20150820000000 20150730000000 3613 example.com. 158 cvTRVrU7dwnemQuBq9/E4tlIiRpvWcEmYdzqs6SCQxw6 159 qmczBBQGldssMx1TCJnwsEs9ZuA2phPzuJNoon9BCA== ) 161 Private-key-format: v1.2 162 Algorithm: TBD (ED25519) 163 PrivateKey: DSSF3o0s0f+ElWzj9E/Osxw8hLpk55chkmx0LYN5WiY= 165 example.com. 3600 IN DNSKEY 257 3 TBD ( 166 zPnZ/QwEe7S8C5SPz2OfS5RR40ATk2/rYnE9xHIEijs= ) 168 example.com. 3600 IN DS 55648 TBD 2 ( 169 96401675bc7ecdd541ec0f70d69238c7b95d3bd4de1e 170 231a068ceb214d02a4ed ) 172 www.example.com. 3600 IN A 192.0.2.1 173 www.example.com. 3600 IN RRSIG A TBD 3 3600 ( 174 20150820000000 20150730000000 35452 example.com. 175 yuGb9rCNIuhDaRJbuhYHj89Y/3Pi8KWUm7lOt00ivVRGvgulmVX8DgpE 176 AFyMP2MKXJrqYJr+ViiCIDwcOIbPAQ==) 178 5. Acknowledgements 180 Some of the material in this document is copied liberally from 181 [RFC6605]. 183 The authors of this document wish to thank Jan Vcelak, Pieter Lexis 184 and Kees Monshouwer for a review of this document. 186 6. IANA Considerations 188 This document updates the IANA registry "Domain Name System Security 189 (DNSSEC) Algorithm Numbers". The following entry has been added to 190 the registry: 192 +--------------+---------------+ 193 | Number | TBD | 194 | Description | Ed25519 | 195 | Mnemonic | ED25519 | 196 | Zone Signing | Y | 197 | Trans. Sec. | * | 198 | Reference | This document | 199 +--------------+---------------+ 201 * There has been no determination of standardization of the use of 202 this algorithm with Transaction Security. 204 7. Implementation Status 206 (Note to the RFC Editor: please remove this entire section as well as 207 the reference to RFC 6982 before publication.) 209 This section records the status of known implementations of the 210 protocol defined by this specification at the time of posting of this 211 Internet-Draft, and is based on a proposal described in [RFC6982]. 212 The description of implementations in this section is intended to 213 assist the IETF in its decision processes in progressing drafts to 214 RFCs. Please note that the listing of any individual implementation 215 here does not imply endorsement by the IETF. Furthermore, no effort 216 has been spent to verify the information presented here that was 217 supplied by IETF contributors. This is not intended as, and must not 218 be construed to be, a catalog of available implementations or their 219 features. Readers are advised to note that other implementations may 220 exist. 222 According to [RFC6982], "this will allow reviewers and working groups 223 to assign due consideration to documents that have the benefit of 224 running code, which may serve as evidence of valuable experimentation 225 and feedback that have made the implemented protocols more mature. 226 It is up to the individual working groups to use this information as 227 they see fit". 229 TODO: Fill out this section. 231 8. Security Considerations 233 The security level of Ed25519 is slightly under the standard 128-bit 234 level ([RFC7748]). Security considerations listed in [RFC7748] also 235 apply to the usage of Ed25519 in DNSSEC. Such an assessment could, 236 of course, change in the future if new attacks that work better than 237 the ones known today are found. 239 9. References 241 9.1. Normative References 243 [I-D.irtf-cfrg-eddsa] 244 Josefsson, S. and I. Liusvaara, "Edwards-curve Digital 245 Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-02 246 (work in progress), January 2016. 248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14, RFC 2119, 250 DOI 10.17487/RFC2119, March 1997, 251 . 253 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 254 Rose, "DNS Security Introduction and Requirements", 255 RFC 4033, DOI 10.17487/RFC4033, March 2005, 256 . 258 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 259 Rose, "Resource Records for the DNS Security Extensions", 260 RFC 4034, DOI 10.17487/RFC4034, March 2005, 261 . 263 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 264 Rose, "Protocol Modifications for the DNS Security 265 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 266 . 268 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 269 for Security", RFC 7748, DOI 10.17487/RFC7748, January 270 2016, . 272 9.2. Informative References 274 [ECCSIZE] van Rijswijk-Deij, R., Speroto, A., and A. Pras, "Making 275 the Case for Elliptic Curves in DNSSEC", 2015, 276 . 279 [ECCSPEED] 280 van Rijswijk-Deij, R. and K. Hageman, "TBD", 2016, . 282 [RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of 283 GOST Signature Algorithms in DNSKEY and RRSIG Resource 284 Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July 285 2010, . 287 [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital 288 Signature Algorithm (DSA) for DNSSEC", RFC 6605, 289 DOI 10.17487/RFC6605, April 2012, 290 . 292 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 293 Code: The Implementation Status Section", RFC 6982, 294 DOI 10.17487/RFC6982, July 2013, 295 . 297 [SafeCurves] 298 Bernstein, D. and T. Lange, "SafeCurves: choosing safe 299 curves for elliptic-curve cryptography", 2016, 300 . 302 Authors' Addresses 304 Ondrej Sury 305 CZ.NIC 306 Milesovska 1136/5 307 Praha 130 00 308 CZ 310 Phone: +420 222 745 111 311 Email: ondrej.sury@nic.cz 313 Robert Edmonds 314 Farsight Security, Inc. 315 177 Bovet Rd #180 316 San Mateo, California 94402 317 US 319 Phone: +1 650 489 7919 320 Email: edmonds@fsi.io