idnits 2.17.1 draft-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 (January 28, 2016) is 3011 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: July 31, 2016 Farsight Security, Inc. 6 January 28, 2016 8 Ed25519 for DNSSEC 9 draft-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 Ed25519 instance of the Edwards- 15 curve Digital Signature Algorithm (EdDSA). 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 July 31, 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: the Ed25519 74 instance of the Edwards-curve Digital Signature Algorithm. A more 75 thorough description of Ed25519 can be found in 76 [I-D.irtf-cfrg-eddsa]. 78 Ed25519 has a 128-bit security target, which is considered to be 79 equivalent in strength to RSA with ~3000-bit keys. Ed25519 public 80 keys are 256 bits (32 bytes) long while signatures are 512 bits (64 81 bytes) long. 83 The usage of the Ed25519 algorithm in DNSSEC has advantages and 84 disadvantages relative to RSA. Ed25519 keys are much shorter than 85 RSA keys. At comparable strengths, Ed25519 keys are 352 bytes 86 smaller than RSA-3072 keys. Similarly, an Ed25519 signature saves 87 320 bytes over an RSA-3072 signature. 89 However, DNSSEC with RSA is not commonly deployed on the Internet 90 with signatures as large as 3072 bits. [RFC6781] contemplates the 91 routine use of RSA-1024 and RSA-2048 in DNSSEC. Even when compared 92 to the use of RSA at reduced strengths, Ed25519 still provides 93 substantially smaller keys and signatures. The authors of Making the 94 Case for Elliptic Curves in DNSSEC [ECCSIZE] study comes to 95 conclusion that using Eliptic Curves in DNSSEC can effectively 96 prevent fragmentation of DNSSEC responses as well as significantly 97 reduce the am- plification attack potential in DNSSEC. 99 Signing with Ed25519 is significantly faster than signing with 100 equivalently strong RSA, and it is also faster than signing with the 101 existing ECDSA algorithms defined in [RFC6605]. However, the 102 validation of RSA signatures is significantly faster than the 103 validation of Ed25519 signatures. The authors of Not Yet Published 104 [ECCSPEED] study comes to conclusion that even if DNSSEC deployment 105 grows to cover 100% of the name space, a resolver will be able to 106 cope with the CPU cycles required to perform validation on a single 107 core. 109 2. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. DNSKEY and RRSIG Resource Records for Ed25519 117 An Ed25519 public key consists of a 32-byte value, which is encoded 118 into the Public Key field of a DNSKEY resource record as a simple bit 119 string. The generation of a public key is defined in Chapter 5.1.5 120 in [I-D.irtf-cfrg-eddsa]. 122 An Ed25519 signature consists of a 64-byte value, which is encoded 123 into the Signature field of an RRSIG resource record as a simple bit 124 string. The Ed25519 signature algorithm is described in Chapter 125 5.1.6 in [I-D.irtf-cfrg-eddsa]. 127 The algorithm number associated with the use of Ed25519 in DS, DNSKEY 128 and RRSIG resource records is TBD. This registration is fully 129 defined in the IANA Considerations section. 131 4. Examples 132 This section needs an update after the algorithm for Ed25519 is 133 assigned. 135 Private-key-format: v1.2 136 Algorithm: TBD (ED25519) 137 PrivateKey: ODIyNjAzODQ2MjgwODAxMjI2NDUxOTAyMDQxNDIyNjI= 138 # corresponding to 82260384628080122645190204142262 INT 140 example.com. 3600 IN DNSKEY 257 3 TBD ( 141 l02Woi0iS8Aa25FQkUd9RMzZHJpBoRQwAQEX1SxZJA4= ) 143 example.com. 3600 IN DS 3613 TBD 2 ( 144 3aa5ab37efce57f737fc1627013fee07bdf241bd10f3 145 b1964ab55c78e79a304b ) 147 www.example.com. 3600 IN A 192.0.2.1 148 www.example.com. 3600 IN RRSIG A TBD 3 3600 ( 149 20150820000000 20150730000000 3613 example.com. 150 cvTRVrU7dwnemQuBq9/E4tlIiRpvWcEmYdzqs6SCQxw6 151 qmczBBQGldssMx1TCJnwsEs9ZuA2phPzuJNoon9BCA== ) 153 Private-key-format: v1.2 154 Algorithm: TBD (ED25519) 155 PrivateKey: DSSF3o0s0f+ElWzj9E/Osxw8hLpk55chkmx0LYN5WiY= 157 example.com. 3600 IN DNSKEY 257 3 TBD ( 158 zPnZ/QwEe7S8C5SPz2OfS5RR40ATk2/rYnE9xHIEijs= ) 160 example.com. 3600 IN DS 55648 TBD 2 ( 161 96401675bc7ecdd541ec0f70d69238c7b95d3bd4de1e 162 231a068ceb214d02a4ed ) 164 www.example.com. 3600 IN A 192.0.2.1 165 www.example.com. 3600 IN RRSIG A TBD 3 3600 ( 166 20150820000000 20150730000000 35452 example.com. 167 yuGb9rCNIuhDaRJbuhYHj89Y/3Pi8KWUm7lOt00ivVRGvgulmVX8DgpE 168 AFyMP2MKXJrqYJr+ViiCIDwcOIbPAQ==) 170 5. Acknowledgements 172 Some of the material in this document is copied liberally from 173 [RFC6605]. 175 The authors of this document wish to thank Jan Vcelak, Pieter Lexis 176 and Kees Monshouwer for a review of this document. 178 6. IANA Considerations 180 This document updates the IANA registry "Domain Name System Security 181 (DNSSEC) Algorithm Numbers". The following entry has been added to 182 the registry: 184 +--------------+---------------+ 185 | Number | TBD | 186 | Description | Ed25519 | 187 | Mnemonic | ED25519 | 188 | Zone Signing | Y | 189 | Trans. Sec. | * | 190 | Reference | This document | 191 +--------------+---------------+ 193 * There has been no determination of standardization of the use of 194 this algorithm with Transaction Security. 196 7. Implementation Status 198 (Note to the RFC Editor: please remove this entire section as well as 199 the reference to RFC 6982 before publication.) 201 This section records the status of known implementations of the 202 protocol defined by this specification at the time of posting of this 203 Internet-Draft, and is based on a proposal described in [RFC6982]. 204 The description of implementations in this section is intended to 205 assist the IETF in its decision processes in progressing drafts to 206 RFCs. Please note that the listing of any individual implementation 207 here does not imply endorsement by the IETF. Furthermore, no effort 208 has been spent to verify the information presented here that was 209 supplied by IETF contributors. This is not intended as, and must not 210 be construed to be, a catalog of available implementations or their 211 features. Readers are advised to note that other implementations may 212 exist. 214 According to [RFC6982], "this will allow reviewers and working groups 215 to assign due consideration to documents that have the benefit of 216 running code, which may serve as evidence of valuable experimentation 217 and feedback that have made the implemented protocols more mature. 218 It is up to the individual working groups to use this information as 219 they see fit". 221 TODO: Fill out this section. 223 8. Security Considerations 225 The security level of Ed25519 is is slightly under the standard 226 128-bit level ([RFC7748]). Security considerations listed in 227 [RFC7748] also apply to the usage of Ed25519 in DNSSEC. Such an 228 assessment could, of course, change in the future if new attacks that 229 work better than the ones known today are found. 231 9. References 233 9.1. Normative References 235 [I-D.irtf-cfrg-eddsa] 236 Josefsson, S. and I. Liusvaara, "Edwards-curve Digital 237 Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-02 238 (work in progress), January 2016. 240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 241 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 242 RFC2119, March 1997, 243 . 245 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 246 Rose, "DNS Security Introduction and Requirements", RFC 247 4033, DOI 10.17487/RFC4033, March 2005, 248 . 250 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 251 Rose, "Resource Records for the DNS Security Extensions", 252 RFC 4034, DOI 10.17487/RFC4034, March 2005, 253 . 255 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 256 Rose, "Protocol Modifications for the DNS Security 257 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 258 . 260 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 261 for Security", RFC 7748, DOI 10.17487/RFC7748, January 262 2016, . 264 9.2. Informative References 266 [ECCSIZE] van Rijswijk-Deij, R., Speroto, A., and A. Pras, "Making 267 the Case for Elliptic Curves in DNSSEC", 2015, 268 . 271 [ECCSPEED] 272 van Rijswijk-Deij, R. and K. Hageman, "TBD", 2016, . 274 [RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of 275 GOST Signature Algorithms in DNSKEY and RRSIG Resource 276 Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July 277 2010, . 279 [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital 280 Signature Algorithm (DSA) for DNSSEC", RFC 6605, DOI 281 10.17487/RFC6605, April 2012, 282 . 284 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 285 Operational Practices, Version 2", RFC 6781, DOI 10.17487/ 286 RFC6781, December 2012, 287 . 289 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 290 Code: The Implementation Status Section", RFC 6982, DOI 291 10.17487/RFC6982, July 2013, 292 . 294 Authors' Addresses 296 Ondrej Sury 297 CZ.NIC 298 Milesovska 1136/5 299 Praha 130 00 300 CZ 302 Phone: +420 222 745 111 303 Email: ondrej.sury@nic.cz 305 Robert Edmonds 306 Farsight Security, Inc. 307 155 Bovet Rd #476 308 San Mateo, California 94402 309 US 311 Phone: +1 650 489 7919 312 Email: edmonds@fsi.io