idnits 2.17.1 draft-ietf-dnsop-algorithm-update-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 abstract seems to contain references ([RFC6944]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (March 21, 2018) is 2226 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) -- Obsolete informational reference (is this intentional?): RFC 6944 (Obsoleted by RFC 8624) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop P. Wouters 3 Internet-Draft Red Hat 4 Obsoletes: 6944 (if approved) O. Sury 5 Intended status: Standards Track Internet Systems Consortium 6 Expires: September 22, 2018 March 21, 2018 8 Algorithm Implementation Requirements and Usage Guidance for DNSSEC 9 draft-ietf-dnsop-algorithm-update-00 11 Abstract 13 The DNSSEC protocol makes use of various cryptographic algorithms in 14 order to provide authentication of DNS data and proof of non- 15 existence. To ensure interoperability between DNS resolvers and DNS 16 authoritative servers, it is necessary to specify a set of algorithm 17 implementation requirements and usage guidance to ensure that there 18 is at least one algorithm that all implementations support. This 19 document defines the current algorithm implementation requirements 20 and usage guidance for DNSSEC. This document obsoletes [RFC6944]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 22, 2018. 39 Copyright Notice 41 Copyright (c) 2018 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 (https://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 Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Updating Algorithm Implementation Requirements and Usage 58 Guidance . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 2 60 1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4 61 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 62 3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 4 64 3.2. DNSKEY Algorithm Recommendation . . . . . . . . . . . . . 5 65 3.3. DS and CDS Algorithms . . . . . . . . . . . . . . . . . . 6 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 5. Operational Considerations . . . . . . . . . . . . . . . . . 7 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 8.2. Informative References . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 The DNSSEC signing algorithms are defined by various RFCs, including 78 [RFC4034], [RFC5155], [RFC5702], [RFC5933], [RFC6605], [RFC8080]. 79 DNSSEC is used to provide authentication of data. To ensure 80 interoperability, a set of "mandatory-to-implement" DNSKEY algorithms 81 are defined. This document obsoletes [RFC6944]. 83 1.1. Updating Algorithm Implementation Requirements and Usage Guidance 85 The field of cryptography evolves continuously. New stronger 86 algorithms appear and existing algorithms are found to be less secure 87 then originally thought. Therefore, algorithm implementation 88 requirements and usage guidance need to be updated from time to time 89 to reflect the new reality. The choices for algorithms must be 90 conservative to minimize the risk of algorithm compromise. 92 1.2. Updating Algorithm Requirement Levels 94 The mandatory-to-implement algorithm of tomorrow should already be 95 available in most implementations of DNSSEC by the time it is made 96 mandatory. This document attempts to identify and introduce those 97 algorithms for future mandatory-to-implement status. There is no 98 guarantee that the algorithms in use today may become mandatory in 99 the future. Published algorithms are continuously subjected to 100 cryptographic attack and may become too weak or could become 101 completely broken before this document is updated. 103 This document only provides recommendations for the mandatory-to- 104 implement algorithms or algorithms too weak that are recommended not 105 to be implemented. As a result, any algorithm listed at the 106 [DNSKEY-IANA] and [DS-IANA] registries not mentioned in this document 107 MAY be implemented. For clarification and consistency, an algorithm 108 will be set to MAY only when it has been downgraded. 110 Although this document updates the algorithms to keep the DNSSEC 111 authentication secure over time, it also aims at providing 112 recommendations so that DNSSEC implementations remain interoperable. 113 DNSSEC interoperability is addressed by an incremental introduction 114 or deprecation of algorithms. 116 While [RFC2119] consider term SHOULD equivalent to RECOMMENDED, and 117 term SHOULD NOT to NOT RECOMMENDED, the authors of this document has 118 chosen to use terms RECOMMENDED and NOT RECOMMENDED, as it better 119 reflects the recommendations for implementations. 121 It is expected that deprecation of an algorithm is performed 122 gradually. This provides time for various implementations to update 123 their implemented algorithms while remaining interoperable. Unless 124 there are strong security reasons, an algorithm is expected to be 125 downgraded from MUST to NOT RECOMMENDED or MAY, instead of MUST NOT. 126 Similarly, an algorithm that has not been mentioned as mandatory-to- 127 implement is expected to be introduced with a RECOMMENDED instead of 128 a MUST. 130 Since the effects of using an unknown DNSKEY algorithm is for the 131 zone to be treated as insecure, it is recommended that algorithms 132 downgraded to NOT RECOMMENDED or below are no longer used by 133 authoritative nameservers and DNSSEC signers to create new DNSKEY's. 134 This will allow for algorithms to slowly become more unused over 135 time. Once deployment has reached a sufficiently low point these 136 algorithms can finally be marked as MUST NOT so that recursive 137 nameservers can remove support for these algorithms. 139 Recursive nameservers are encouraged to keep support for all 140 algorithms not marked as MUST NOT. 142 1.3. Document Audience 144 The recommendations of this document mostly target DNSSEC 145 implementers as implementations need to meet both high security 146 expectations as well as high interoperability between various vendors 147 and with different versions. Interoperability requires a smooth move 148 to more secure algorithms. This may differ from a user point of view 149 that may deploy and configure DNSSEC with only the safest algorithm. 150 On the other hand, comments and recommendations from this document 151 are also expected to be useful for such users. 153 2. Conventions Used in This Document 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 3. Algorithm Selection 161 3.1. DNSKEY Algorithms 163 Implemenation recommendations for DNSKEY algorithms [DNSKEY-IANA]. 165 +--------+--------------------+-----------------+-------------------+ 166 | Number | Mnemonics | DNSSEC Signing | DNSSEC Validation | 167 +--------+--------------------+-----------------+-------------------+ 168 | 1 | RSAMD5 | MUST NOT | MUST NOT | 169 | 3 | DSA | MUST NOT | MUST NOT | 170 | 5 | RSASHA1 | NOT RECOMMENDED | MUST | 171 | 6 | DSA-NSEC3-SHA1 | MUST NOT | MUST NOT | 172 | 7 | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST | 173 | 8 | RSASHA256 | MUST | MUST | 174 | 10 | RSASHA512 | NOT RECOMMENDED | MUST | 175 | 12 | ECC-GOST | MUST NOT | MAY | 176 | 13 | ECDSAP256SHA256 | MUST | MUST | 177 | 14 | ECDSAP384SHA384 | NOT RECOMMENDED | RECOMMENDED | 178 | 15 | ED25519 | RECOMMENDED | RECOMMENDED | 179 | 16 | ED448 | MAY | RECOMMENDED | 180 +--------+--------------------+-----------------+-------------------+ 182 RSAMD5 is not widely deployed and there is an industry-wide trend to 183 deprecate MD5 usage. 185 RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones 186 deploying it are recommended to switch to ECDSAP256SHA256 as there is 187 an industry-wide trend to move to elliptic curve cryptography. 188 RSASHA1 does not support NSEC3. RSASHA1-NSEC3-SHA1 can be used with 189 or without NSEC3. 191 DSA and DSA-NSEC3-SHA1 are not widely deployed and vulnerable to 192 private key compromise when generating signatures using a weak or 193 compromised random number generator. 195 RSASHA256 is in wide use and considered strong. 197 RSASHA512 is NOT RECOMMENDED for DNSSEC Signing because it has not 198 seen wide deployment, but there are some deployments hence DNSSEC 199 Validation MUST implement RSASHA512 to ensure interoperability. 200 There's isn't significant difference in cryptographics strength 201 between RSASHA512 and RSASHA256, therefore it is discouraged to use 202 RSASHA512, as it will only make deprecation of older algorithms 203 harder. People that want to use cryptographically stronger algorithm 204 should switch to elliptic curve cryptography algorithms. 206 ECC-GOST (GOST R 34.11-94) has been superseded by GOST R 34.11-2012 207 in [RFC6986]. The GOST R 34.11-2012 hasn't been standardized for use 208 in DNSSEC. 210 ECDSAP256SHA256 provide more strength for signature size than 211 RSASHA256 and RSASHA512 variants. ECDSAP256SHA256 has been widely 212 deployed and therefore it is now at MUST level for both validation 213 and signing. It is RECOMMENDED to use deterministic digital 214 signature generation procedure of the ECDSA ([RFC6979]) when 215 implementing ECDSAP256SHA256 (and ECDSAP384SHA384). 217 ECDSAP384SHA384 share the same properties as ECDSAP256SHA256, but 218 offers only a little advantage over ECDSAP256SHA256 and has not seen 219 wide deployment, so the usage of this algorithm is discouraged, 220 especially for signing. 222 ED25519 and ED448 uses Edwards-curve Digital Security Algorithm 223 (EdDSA). There are three main advantages of the EdDSA algorithm: It 224 does not require the use of a unique random number for each 225 signature, there are no padding or truncation issues as with ECDSA, 226 and it is more resilient to side-channel attacks. Furthermore, EdDSA 227 cryptography is less prone to implementation errors ([RFC8080]). It 228 is expected that ED25519 will become the future RECOMMENDED default 229 algorithm once there's enough support for this algorithm in the 230 deployed DNSSEC validators. 232 3.2. DNSKEY Algorithm Recommendation 234 Operation recommendation for new and existing deployments. 236 Due to industry-wide trend to move to elliptic curve cryptography, 237 the ECDSAP256SHA256 is RECOMMENDED to be used by new DNSSEC 238 deployments, and users of RSA based algorithms SHOULD upgrade to 239 ECDSAP256SHA256. 241 3.3. DS and CDS Algorithms 243 Recommendations for Delegation Signer Digest Algorithms [DNSKEY-IANA] 244 These also apply to the CDS RRTYPE as specified in [RFC7344] 246 +--------+-----------------+-------------------+-------------------+ 247 | Number | Mnemonics | DNSSEC Delegation | DNSSEC Validation | 248 +--------+-----------------+-------------------+-------------------+ 249 | 0 | NULL (CDS only) | MUST NOT [*] | MUST NOT [*] | 250 | 1 | SHA-1 | MUST NOT | MUST | 251 | 2 | SHA-256 | MUST | MUST | 252 | 3 | GOST R 34.11-94 | MUST NOT | MAY | 253 | 4 | SHA-384 | MAY | RECOMMENDED | 254 +--------+-----------------+-------------------+-------------------+ 256 [*] - This is a special type of CDS record signaling removal of DS at 257 the parent in [RFC8078] 259 NULL is a special case, see [RFC8078] 261 SHA-1 is still in wide use for DS records, so validators MUST 262 implement the validation, but it is disallowed to use SHA-1 to 263 generate new DS records. (See Operational Considerations for caveats 264 when upgrading from SHA-1 to SHA-256 DS Algorithm.) 266 SHA-256 is in wide use and considered strong. 268 GOST R 34.11-94 has been deprecated by [RFC6986]. 270 SHA-384 is not in wide use. It is still recommended to be supported 271 in validators so that adoption can increase. 273 4. Security Considerations 275 The security of cryptographic-based systems depends on both the 276 strength of the cryptographic algorithms chosen and the strength of 277 the keys used with those algorithms. The security also depends on 278 the engineering of the protocol used by the system to ensure that 279 there are no non-cryptographic ways to bypass the security of the 280 overall system. 282 This document concerns itself with the selection of cryptographic 283 algorithms for the use of DNSSEC, specifically with the selection of 284 "mandatory-to-implement" algorithms. The algorithms identified in 285 this document as MUST or RECOMMENDED to implement are not known to be 286 broken at the current time, and cryptographic research so far leads 287 us to believe that they will likely remain secure into the 288 foreseeable future. However, this isn't necessarily forever and it 289 is expected that new revisions of this document will be issued from 290 time to time to reflect the current best practice in this area. 292 Retiring an algorithm too soon would result in a signed zone with 293 such an algorithm to be downgraded to the equivalent of an unsigned 294 zone. Therefore, algorithm deprecation must be done very slowly and 295 only after careful consideration and measurements of its use. 297 5. Operational Considerations 299 DNSKEY algorithm rollover in a live zone is a complex process. See 300 [RFC6781] and [RFC7583] for guidelines on how to perform algorithm 301 rollovers. 303 DS algorithm rollover in a live zone is also a complex process. 304 Upgrading algorithm at the same time as rolling the new KSK key will 305 lead to DNSSEC validation failures, and users MUST upgrade the DS 306 algorithm first before rolling the Key Signing Key. 308 6. IANA Considerations 310 This document makes no requests of IANA. 312 7. Acknowledgements 314 This document borrows text from RFC 4307 by Jeffrey I. Schiller of 315 the Massachusetts Institute of Technology (MIT) and the 4307bis 316 document by Yoav Nir, Tero Kivinen, Paul Wouters and Daniel Migault. 317 Much of the original text has been copied verbatim. 319 We wish to thank Roland van Rijswijk-Deij, Olafur Gudmundsson and 320 Paul Hoffman for their imminent feedback. 322 Kudos to Roy Arends for bringing the DS rollover issue to the 323 daylight. 325 8. References 327 8.1. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, 331 DOI 10.17487/RFC2119, March 1997, 332 . 334 8.2. Informative References 336 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 337 Rose, "Resource Records for the DNS Security Extensions", 338 RFC 4034, DOI 10.17487/RFC4034, March 2005, 339 . 341 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 342 Security (DNSSEC) Hashed Authenticated Denial of 343 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 344 . 346 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 347 and RRSIG Resource Records for DNSSEC", RFC 5702, 348 DOI 10.17487/RFC5702, October 2009, 349 . 351 [RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of 352 GOST Signature Algorithms in DNSKEY and RRSIG Resource 353 Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July 354 2010, . 356 [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital 357 Signature Algorithm (DSA) for DNSSEC", RFC 6605, 358 DOI 10.17487/RFC6605, April 2012, 359 . 361 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 362 Operational Practices, Version 2", RFC 6781, 363 DOI 10.17487/RFC6781, December 2012, 364 . 366 [RFC6944] Rose, S., "Applicability Statement: DNS Security (DNSSEC) 367 DNSKEY Algorithm Implementation Status", RFC 6944, 368 DOI 10.17487/RFC6944, April 2013, 369 . 371 [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature 372 Algorithm (DSA) and Elliptic Curve Digital Signature 373 Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 374 2013, . 376 [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: 377 Hash Function", RFC 6986, DOI 10.17487/RFC6986, August 378 2013, . 380 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 381 DNSSEC Delegation Trust Maintenance", RFC 7344, 382 DOI 10.17487/RFC7344, September 2014, 383 . 385 [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, 386 "DNSSEC Key Rollover Timing Considerations", RFC 7583, 387 DOI 10.17487/RFC7583, October 2015, 388 . 390 [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from 391 the Parent via CDS/CDNSKEY", RFC 8078, 392 DOI 10.17487/RFC8078, March 2017, 393 . 395 [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security 396 Algorithm (EdDSA) for DNSSEC", RFC 8080, 397 DOI 10.17487/RFC8080, February 2017, 398 . 400 [DNSKEY-IANA] 401 "DNSKEY Algorithms", . 404 [DS-IANA] "Delegation Signer Digest Algorithms", 405 . 408 Authors' Addresses 410 Paul Wouters 411 Red Hat 412 CA 414 EMail: pwouters@redhat.com 416 Ondrej Sury 417 Internet Systems Consortium 418 CZ 420 EMail: ondrej@isc.org