idnits 2.17.00 (12 Aug 2021) /tmp/idnits23895/draft-wouters-sury-dnsop-algorithm-update-02.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 draft header indicates that this document obsoletes RFC6944, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 11, 2016) is 2041 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) == Outdated reference: draft-ietf-curdle-dnskey-eddsa has been published as RFC 8080 == Outdated reference: draft-ietf-dnsop-maintain-ds has been published as RFC 8078 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 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 CZ.NIC 6 Expires: April 14, 2017 October 11, 2016 8 Algorithm Implementation Requirements and Usage Guidance for DNSSEC 9 draft-wouters-sury-dnsop-algorithm-update-02 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 RFC-6944. 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 http://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 April 14, 2017. 39 Copyright Notice 41 Copyright (c) 2016 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 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 . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 62 3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 4 64 3.2. DS and CDS Algorithms . . . . . . . . . . . . . . . . . . 5 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 5. Operational Considerations . . . . . . . . . . . . . . . . . 7 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 8.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 The DNSSEC signing algorithms are defined by various RFCs, including 77 [RFC4034], [RFC5155], [RFC5702], [RFC5933], [RFC6605], 78 [I-D.ietf-curdle-dnskey-eddsa]. DNSSEC is used to provide 79 authentication of data. To ensure interoperability, a set of 80 "mandatory-to-implement" DNSKEY algorithms are defined. This 81 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 It is expected that deprecation of an algorithm is performed 117 gradually. This provides time for various implementations to update 118 their implemented algorithms while remaining interoperable. Unless 119 there are strong security reasons, an algorithm is expected to be 120 downgraded from MUST to MUST- or SHOULD, instead of MUST NOT. 121 Similarly, an algorithm that has not been mentioned as mandatory-to- 122 implement is expected to be introduced with a SHOULD instead of a 123 MUST. 125 Since the effects of using an unknown DNSKEY algorithm is for the 126 zone to be treated as insecure, it is recommended that algorithms 127 downgraded to SHOULD- or below are no longer used by authoritative 128 nameservers and DNSSEC signers to create new DNSKEY's. This will 129 allow for algorithms to slowly become more unused over time. Once 130 deployment has reached a sufficiently low point these algorithms can 131 finally be marked as MUST NOT so that recursive nameservers can 132 remove support for these algorithms. 134 Recursive nameservers are encouraged to keep support for all 135 algorithms not marked as MUST NOT. 137 1.3. Document Audience 139 The recommendations of this document mostly target DNSSEC 140 implementers as implementations need to meet both high security 141 expectations as well as high interoperability between various vendors 142 and with different versions. Interoperability requires a smooth move 143 to more secure algorithms. This may differ from a user point of view 144 that may deploy and configure DNSSEC with only the safest algorithm. 146 On the other hand, comments and recommendations from this document 147 are also expected to be useful for such users. 149 2. Conventions Used in This Document 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 We define some additional terms here: 157 SHOULD+ This term means the same as SHOULD. However, it is likely 158 that an algorithm marked as SHOULD+ will be promoted at 159 some future time to be a MUST. 160 SHOULD- This term means the same as SHOULD. However, an algorithm 161 marked as SHOULD- may be deprecated to a MAY in a future 162 version of this document. 163 MUST- This term means the same as MUST. However, it is expected 164 at some point in the near future that this algorithm will 165 no longer be a MUST in a future document. Although its 166 status will be determined at a later time, it is reasonable 167 to expect that if a future revision of a document alters 168 the status of a MUST- algorithm, it will remain at least a 169 SHOULD or a SHOULD-. 171 3. Algorithm Selection 173 3.1. DNSKEY Algorithms 175 Recommendations for DNSKEY algorithms [DNSKEY-IANA] 177 +--------+--------------------+----------------+-------------------+ 178 | Number | Mnemonics | DNSSEC Signing | DNSSEC Validation | 179 +--------+--------------------+----------------+-------------------+ 180 | 1 | RSAMD5 | MUST NOT | MUST NOT | 181 | 3 | DSA | MUST NOT | MUST NOT | 182 | 5 | RSASHA1 | MUST- | MUST- | 183 | 6 | DSA-NSEC3-SHA1 | MUST NOT | MUST NOT | 184 | 7 | RSASHA1-NSEC3-SHA1 | MUST- | MUST- | 185 | 8 | RSASHA256 | MUST | MUST | 186 | 10 | RSASHA512 | SHOULD- | MUST | 187 | 12 | ECC-GOST | SHOULD NOT | SHOULD- | 188 | 13 | ECDSAP256SHA256 | SHOULD- | MUST- | 189 | 14 | ECDSAP384SHA384 | SHOULD NOT | SHOULD- | 190 | TBD | ED25519 | SHOULD+ | SHOULD+ | 191 | TBD | ED448 | SHOULD+ | SHOULD+ | 192 +--------+--------------------+----------------+-------------------+ 193 RSAMD5 is not widely deployed and there is an industry-wide trend to 194 deprecate MD5 usage. 196 RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones 197 deploying it are recommended to switch to RSASHA256 as there is an 198 industry-wide trend to deprecate SHA1 usage. RSASHA1 does not 199 support NSEC3. RSASHA1-NSEC3-SHA1 can be used with or without NSEC3. 201 DSA and DSA-NSEC3-SHA1 are not widely deployed and vulnerable to 202 private key compromise when generating signatures using a weak or 203 compromised random number generator. 205 RSASHA512 is at the SHOULD level for DNSSEC Signing because it has 206 not seen wide deployment, but there are some deployments hence DNSSEC 207 Validation MUST implement RSASHA512 to ensure interoperability. 209 ECC-GOST is at the SHOULD NOT level because it has not seen wide 210 deployment and the algorithm has not seen wide scrutiny in the crypto 211 community. 213 ECDSAP256SHA256 and ECDSAP384SHA384 provide more strength for 214 signature size than RSASHA256 and RSASHA512 variants. 215 ECDSAP256SHA256 has seen increased deployment and has been raised to 216 MUST- level for resolving and SHOULD- for signing. It is seen as a 217 temporary improvement over RSA until the 218 [I-D.ietf-curdle-dnskey-eddsa] algorithms are published, implemented 219 and deployed. ECDSAP384SHA384 offers little over ECDSAP256SHA256 and 220 has not seen wide deployment, so the use is discouraged, especially 221 for signing. 223 ED25519 and ED448 uses Edwards-curve Digital Security Algorithm 224 (EdDSA). There are three main advantages of the EdDSA algorithm: It 225 does not require the use of a unique random number for each 226 signature, there are no padding or truncation issues as with ECDSA, 227 and it is more resilient to side-channel attacks. Hence it is 228 expected that these algorithms will be raised to SHOULD for signing 229 and MUST for resolving once it has seen more implementations and 230 deployement. 232 3.2. DS and CDS Algorithms 234 Recommendations for Delegation Signer Digest Algorithms [DNSKEY-IANA] 235 These also apply to the CDS RRTYPE as specified in [RFC7344] 236 +--------+-----------------+-------------------+-------------------+ 237 | Number | Mnemonics | DNSSEC Delegation | DNSSEC Validation | 238 +--------+-----------------+-------------------+-------------------+ 239 | 0 | NULL (CDS only) | MUST NOT [*] | MUST NOT [*] | 240 | 1 | SHA-1 | SHOULD NOT | MUST- | 241 | 2 | SHA-256 | MUST | MUST | 242 | 3 | GOST R 34.11-94 | MAY | SHOULD | 243 | 4 | SHA-384 | MAY | SHOULD+ | 244 +--------+-----------------+-------------------+-------------------+ 246 [*] - This is a special type of CDS record signaling removal of DS at 247 the parent in [I-D.ietf-dnsop-maintain-ds] 249 NULL is a special case, see [I-D.ietf-dnsop-maintain-ds] 251 SHA-1 is in wide use for DS records, but its use is discouraged as it 252 is an aging algorithm. Users of SHA-1 SHOULD upgrade to SHA-256. 254 SHA-256 is in wide use and considered strong. 256 GOST R 34.11-94 is not in wide use. It is still recommended to be 257 supported in validators so that adoption can increase. 259 SHA-384 is not in wide use. It is still recommended to be supported 260 in validators so that adoption can increase. 262 4. Security Considerations 264 The security of cryptographic-based systems depends on both the 265 strength of the cryptographic algorithms chosen and the strength of 266 the keys used with those algorithms. The security also depends on 267 the engineering of the protocol used by the system to ensure that 268 there are no non-cryptographic ways to bypass the security of the 269 overall system. 271 This document concerns itself with the selection of cryptographic 272 algorithms for the use of DNSSEC, specifically with the selection of 273 "mandatory-to-implement" algorithms. The algorithms identified in 274 this document as "MUST implement" or "SHOULD implement" are not known 275 to be broken at the current time, and cryptographic research so far 276 leads us to believe that they will likely remain secure into the 277 foreseeable future. However, this isn't necessarily forever and it 278 is expected that new revisions of this document will be issued from 279 time to time to reflect the current best practice in this area. 281 Retiring an algorithm too soon would result in a signed zone with 282 such an algorithm to be downgraded to the equivalent of an unsigned 283 zone. Therefore, algorithm deprecation must be done very slowly and 284 only after careful consideration and measurements of its use. 286 5. Operational Considerations 288 DNSKEY algorithm rollover in a live zone is a complex process. See 289 [RFC6781] and [RFC7583] for guidelines on how to perform algorithm 290 rollovers. 292 6. IANA Considerations 294 This document makes no requests of IANA. 296 7. Acknowledgements 298 This document borrows text from RFC 4307 by Jeffrey I. Schiller of 299 the Massachusetts Institute of Technology (MIT) and the 4307bis 300 document by Yoav Nir, Tero Kivinen, Paul Wouters and Daniel Migault. 301 Much of the original text has been copied verbatim. 303 We wish to thank Olafur Gudmundsson and Paul Hoffman for their 304 imminent feedback. 306 8. References 308 8.1. Normative References 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, 312 DOI 10.17487/RFC2119, March 1997, 313 . 315 8.2. Informative References 317 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 318 Rose, "Resource Records for the DNS Security Extensions", 319 RFC 4034, DOI 10.17487/RFC4034, March 2005, 320 . 322 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 323 Security (DNSSEC) Hashed Authenticated Denial of 324 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 325 . 327 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 328 and RRSIG Resource Records for DNSSEC", RFC 5702, 329 DOI 10.17487/RFC5702, October 2009, 330 . 332 [RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of 333 GOST Signature Algorithms in DNSKEY and RRSIG Resource 334 Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July 335 2010, . 337 [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital 338 Signature Algorithm (DSA) for DNSSEC", RFC 6605, 339 DOI 10.17487/RFC6605, April 2012, 340 . 342 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 343 Operational Practices, Version 2", RFC 6781, 344 DOI 10.17487/RFC6781, December 2012, 345 . 347 [RFC6944] Rose, S., "Applicability Statement: DNS Security (DNSSEC) 348 DNSKEY Algorithm Implementation Status", RFC 6944, 349 DOI 10.17487/RFC6944, April 2013, 350 . 352 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 353 DNSSEC Delegation Trust Maintenance", RFC 7344, 354 DOI 10.17487/RFC7344, September 2014, 355 . 357 [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, 358 "DNSSEC Key Rollover Timing Considerations", RFC 7583, 359 DOI 10.17487/RFC7583, October 2015, 360 . 362 [I-D.ietf-curdle-dnskey-eddsa] 363 Sury, O. and R. Edmonds, "EdDSA for DNSSEC", draft-ietf- 364 curdle-dnskey-eddsa-01 (work in progress), October 2016. 366 [I-D.ietf-dnsop-maintain-ds] 367 Gudmundsson, O. and P. Wouters, "Managing DS records from 368 parent via CDS/CDNSKEY", draft-ietf-dnsop-maintain-ds-03 369 (work in progress), June 2016. 371 [DNSKEY-IANA] 372 "DNSKEY Algorithms", . 375 [DS-IANA] "Delegation Signer Digest Algorithms", 376 . 379 Authors' Addresses 381 Paul Wouters 382 Red Hat 384 EMail: pwouters@redhat.com 386 Ondrej Sury 387 CZ.NIC 389 EMail: ondrej.sury@nic.cz