idnits 2.17.1 draft-sury-dnskey-ed448-00.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 (September 8, 2015) is 3125 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) ** Downref: Normative reference to an Informational draft: draft-josefsson-eddsa-ed25519 (ref. 'I-D.josefsson-eddsa-ed25519') -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 1 error (**), 0 flaws (~~), 2 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: March 11, 2016 Farsight Security, Inc. 6 September 8, 2015 8 Ed448 for DNSSEC 9 draft-sury-dnskey-ed448-00 11 Abstract 13 This document describes how to specify Ed448 keys and signatures in 14 DNS Security (DNSSEC). It uses the Ed448 instance of the Edwards- 15 curve Digital Signature Algorithm (EdDSA) with the SHA-512 hash 16 algorithm. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 11, 2016. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 54 3. DNSKEY and RRSIG Resource Records for Ed448 . . . . . . . . . 3 55 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 59 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 62 9.2. Informative References . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 DNSSEC, which is broadly defined in [RFC4033], [RFC4034], and 68 [RFC4035], uses cryptographic keys and digital signatures to provide 69 authentication of DNS data. Currently, the most popular signature 70 algorithm in use is RSA. [RFC5933] and [RFC6605] later defined the 71 use of GOST and NIST specified elliptic curve cryptography in DNSSEC. 73 This document defines the use of DNSSEC's DS, DNSKEY, and RRSIG 74 resource records (RRs) with a new signing algorithm: the Ed448 75 instance of the Edwards-curve Digital Signature Algorithm (EdDSA) 76 used with the SHA-512 hash algorithm. A more thorough description of 77 Ed448 can be found in (TODO: Simon is going to add Ed448 to his 78 draft) [I-D.josefsson-eddsa-ed25519]. 80 Ed448 has a 224-bit security target, which is considered to be 81 equivalent in strength to RSA with ~12000-bit keys. Ed448 public 82 keys are 448 bits (56 bytes) long while signatures are 896 bits (112 83 bytes) long. The curve is meant as a more conservative alternative 84 to Ed25519. 86 The usage of the Ed448 algorithm in DNSSEC has advantages and 87 disadvantages relative to RSA. Ed448 keys are much shorter than RSA 88 keys. At RSA-4096 strength that is the maximum defined for DNSSEC, 89 Ed448 keys are 456 bytes smaller than RSA-4096 keys. Similarly, an 90 Ed448 signature saves 400 bytes over an RSA-4096 signature. 92 However, DNSSEC with RSA is not commonly deployed on the Internet 93 with signatures as large as 3072 bits. [RFC6781] contemplates the 94 routine use of RSA-1024 and RSA-2048 in DNSSEC. Even when compared 95 to the use of RSA at reduced strengths, Ed448 still provides smaller 96 keys and signatures. 98 TODO - this is boilerplate :), we need to see the numbers. Signing 99 with Ed448 is significantly faster than signing with equivalently 100 strong RSA. However, the validation of RSA signatures is 101 significantly faster than the validation of Ed448 signatures. 103 2. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 3. DNSKEY and RRSIG Resource Records for Ed448 111 An Ed448 public key consists of a 56-byte value that represents the 112 compressed encoding of the curve point, which is encoded into the 113 Public Key field of a DNSKEY resource record as a simple bit string. 114 The generation of a public key is defined in Chapter 5.5 in 115 [I-D.josefsson-eddsa-ed25519]. (TODO) 117 An Ed448 signature consists of a 112-byte value, which is encoded 118 into the Signature field of an RRSIG resource record as a simple bit 119 string. The Ed448 signature algorithm is described in Chapter 5.6 in 120 [I-D.josefsson-eddsa-ed25519]. (TODO) 122 The algorithm number associated with the use of Ed448 with SHA-512 in 123 DS, DNSKEY and RRSIG resource records is TBD. This registration is 124 fully defined in the IANA Considerations section. 126 4. Examples 127 This section needs an update after the algorithm for Ed448 is 128 assigned. NOTE: Also the examples are copied from Ed25519 draft and 129 they need to be replaces with real examples. 131 Private-key-format: v1.2 132 Algorithm: TBD (ED448SHA512) 133 PrivateKey: ODIyNjAzODQ2MjgwODAxMjI2NDUxOTAyMDQxNDIyNjI= 134 # corresponding to 82260384628080122645190204142262 INT 136 example.com. 3600 IN DNSKEY 257 3 TBD ( 137 l02Woi0iS8Aa25FQkUd9RMzZHJpBoRQwAQEX1SxZJA4= ) 139 example.com. 3600 IN DS 3613 TBD 2 ( 140 3aa5ab37efce57f737fc1627013fee07bdf241bd10f3 141 b1964ab55c78e79a304b ) 143 www.example.com. 3600 IN A 192.0.2.1 144 www.example.com. 3600 IN RRSIG A TBD 3 3600 ( 145 20150820000000 20150730000000 3613 example.com. 146 cvTRVrU7dwnemQuBq9/E4tlIiRpvWcEmYdzqs6SCQxw6 147 qmczBBQGldssMx1TCJnwsEs9ZuA2phPzuJNoon9BCA== ) 149 Private-key-format: v1.2 150 Algorithm: TBD (ED448SHA512) 151 PrivateKey: DSSF3o0s0f+ElWzj9E/Osxw8hLpk55chkmx0LYN5WiY= 153 example.com. 3600 IN DNSKEY 257 3 TBD ( 154 zPnZ/QwEe7S8C5SPz2OfS5RR40ATk2/rYnE9xHIEijs= ) 156 example.com. 3600 IN DS 55648 TBD 2 ( 157 96401675bc7ecdd541ec0f70d69238c7b95d3bd4de1e 158 231a068ceb214d02a4ed ) 160 www.example.com. 3600 IN A 192.0.2.1 161 www.example.com. 3600 IN RRSIG A TBD 3 3600 ( 162 20150820000000 20150730000000 35452 example.com. 163 yuGb9rCNIuhDaRJbuhYHj89Y/3Pi8KWUm7lOt00ivVRGvgulmVX8DgpE 164 AFyMP2MKXJrqYJr+ViiCIDwcOIbPAQ==) 166 5. Acknowledgements 168 Some of the material in this document is copied liberally from 169 [RFC6605]. 171 The authors of this document wish to thank Jan Vcelak, Pieter Lexis 172 and Kees Monshouwer for a review of this document. 174 6. IANA Considerations 176 This document updates the IANA registry "Domain Name System Security 177 (DNSSEC) Algorithm Numbers". The following entry has been added to 178 the registry: 180 +--------------+--------------------+ 181 | Number | TBD | 182 | Description | Ed448 with SHA-512 | 183 | Mnemonic | ED448SHA512 | 184 | Zone Signing | Y | 185 | Trans. Sec. | * | 186 | Reference | This document | 187 +--------------+--------------------+ 189 * There has been no determination of standardization of the use of 190 this algorithm with Transaction Security. 192 7. Implementation Status 194 (Note to the RFC Editor: please remove this entire section as well as 195 the reference to RFC 6982 before publication.) 197 This section records the status of known implementations of the 198 protocol defined by this specification at the time of posting of this 199 Internet-Draft, and is based on a proposal described in [RFC6982]. 200 The description of implementations in this section is intended to 201 assist the IETF in its decision processes in progressing drafts to 202 RFCs. Please note that the listing of any individual implementation 203 here does not imply endorsement by the IETF. Furthermore, no effort 204 has been spent to verify the information presented here that was 205 supplied by IETF contributors. This is not intended as, and must not 206 be construed to be, a catalog of available implementations or their 207 features. Readers are advised to note that other implementations may 208 exist. 210 According to [RFC6982], "this will allow reviewers and working groups 211 to assign due consideration to documents that have the benefit of 212 running code, which may serve as evidence of valuable experimentation 213 and feedback that have made the implemented protocols more mature. 214 It is up to the individual working groups to use this information as 215 they see fit". 217 TODO: Fill out this section. 219 8. Security Considerations 221 Ed448 is targeted to provide attack resistance comparable to quality 222 224-bit symmetric ciphers. Such an assessment could, of course, 223 change in the future if new attacks that work better than the ones 224 known today are found. 226 9. References 228 9.1. Normative References 230 [I-D.josefsson-eddsa-ed25519] 231 Josefsson, S. and N. Moller, "EdDSA and Ed25519", draft- 232 josefsson-eddsa-ed25519-03 (work in progress), May 2015. 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 236 RFC2119, March 1997, 237 . 239 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 240 Rose, "DNS Security Introduction and Requirements", RFC 241 4033, DOI 10.17487/RFC4033, March 2005, 242 . 244 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 245 Rose, "Resource Records for the DNS Security Extensions", 246 RFC 4034, DOI 10.17487/RFC4034, March 2005, 247 . 249 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 250 Rose, "Protocol Modifications for the DNS Security 251 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 252 . 254 9.2. Informative References 256 [RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of 257 GOST Signature Algorithms in DNSKEY and RRSIG Resource 258 Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July 259 2010, . 261 [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital 262 Signature Algorithm (DSA) for DNSSEC", RFC 6605, DOI 263 10.17487/RFC6605, April 2012, 264 . 266 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 267 Operational Practices, Version 2", RFC 6781, DOI 10.17487/ 268 RFC6781, December 2012, 269 . 271 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 272 Code: The Implementation Status Section", RFC 6982, DOI 273 10.17487/RFC6982, July 2013, 274 . 276 Authors' Addresses 278 Ondrej Sury 279 CZ.NIC 280 Milesovska 1136/5 281 Praha 130 00 282 CZ 284 Phone: +420 222 745 111 285 Email: ondrej.sury@nic.cz 287 Robert Edmonds 288 Farsight Security, Inc. 289 155 Bovet Rd #476 290 San Mateo, California 94402 291 US 293 Phone: +1 650 489 7919 294 Email: edmonds@fsi.io