idnits 2.17.00 (12 Aug 2021) /tmp/idnits28246/draft-wouters-sury-dnsop-algorithm-update-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. -- 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 (March 21, 2016) is 2251 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) == Unused Reference: 'DS-IANA' is defined on line 380, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 6944 (Obsoleted by RFC 8624) == Outdated reference: draft-ietf-dnsop-maintain-ds has been published as RFC 8078 Summary: 1 error (**), 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: September 22, 2016 March 21, 2016 8 Algorithm Implementation Requirements and Usage Guidance for DNSSEC 9 draft-wouters-sury-dnsop-algorithm-update-01 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 September 22, 2016. 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 73 1. Introduction 75 The DNSSEC signing algorithms are defined by various RFCs, including 76 [RFC4034], [RFC5155], [RFC5702], [RFC5933], [RFC6605], 77 [I-D.ietf-curdle-dnskey-ed25519] and [I-D.ietf-curdle-dnskey-ed448]. 78 DNSSEC is used to provide authentication of data. To ensure 79 interoperability, a set of "mandatory-to-implement" DNSKEY algorithms 80 are defined. This document obsoletes [RFC6944]. 82 1.1. Updating Algorithm Implementation Requirements and Usage Guidance 84 The field of cryptography evolves continuously. New stronger 85 algorithms appear and existing algorithms are found to be less secure 86 then originally thought. Therefore, algorithm implementation 87 requirements and usage guidance need to be updated from time to time 88 to reflect the new reality. The choices for algorithms must be 89 conservative to minimize the risk of algorithm compromise. 91 1.2. Updating Algorithm Requirement Levels 93 The mandatory-to-implement algorithm of tomorrow should already be 94 available in most implementations of DNSSEC by the time it is made 95 mandatory. This document attempts to identify and introduce those 96 algorithms for future mandatory-to-implement status. There is no 97 guarantee that the algorithms in use today may become mandatory in 98 the future. Published algorithms are continuously subjected to 99 cryptographic attack and may become too weak or could become 100 completely broken before this document is updated. 102 This document only provides recommendations for the mandatory-to- 103 implement algorithms or algorithms too weak that are recommended not 104 to be implemented. As a result, any algorithm listed at the 105 [DNSKEY-IANA] registry not mentioned in this document MAY be 106 implemented. For clarification and consistency, an algorithm will be 107 set to MAY only when it has been downgraded. 109 Although this document updates the algorithms to keep the DNSSEC 110 authentication secure over time, it also aims at providing 111 recommendations so that DNSSEC implementations remain interoperable. 112 DNSSEC interoperability is addressed by an incremental introduction 113 or deprecation of algorithms. 115 It is expected that deprecation of an algorithm is performed 116 gradually. This provides time for various implementations to update 117 their implemented algorithms while remaining interoperable. Unless 118 there are strong security reasons, an algorithm is expected to be 119 downgraded from MUST to MUST- or SHOULD, instead of MUST NOT. 120 Similarly, an algorithm that has not been mentioned as mandatory-to- 121 implement is expected to be introduced with a SHOULD instead of a 122 MUST. 124 Since the effects of using an unknown DNSKEY algorithm is for the 125 zone to be treated as insecure, it is recommended that algorithms 126 downgraded to SHOULD- or below are no longer used by authoritative 127 nameservers and DNSSEC signers to create new DNSKEY's. This will 128 allow for algorithms to slowly become more unused over time. Once 129 deployment has reached a sufficiently low point these algorithms can 130 finally be marked as MUST NOT so that recursive nameservers can 131 remove support for these algorithms. 133 Recursive nameservers are encouraged to keep support for all 134 algorithms not marked as MUST NOT. 136 1.3. Document Audience 137 The recommendations of this document mostly target DNSSEC 138 implementers as implementations need to meet both high security 139 expectations as well as high interoperability between various vendors 140 and with different versions. Interoperability requires a smooth move 141 to more secure algorithms. This may differ from a user point of view 142 that may deploy and configure DNSSEC with only the safest algorithm. 143 On the other hand, comments and recommendations from this document 144 are also expected to be useful for such users. 146 2. Conventions Used in This Document 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. 152 We define some additional terms here: 154 SHOULD+ This term means the same as SHOULD. However, it is likely 155 that an algorithm marked as SHOULD+ will be promoted at some 156 future time to be a MUST. 157 SHOULD- This term means the same as SHOULD. However, an algorithm 158 marked as SHOULD- may be deprecated to a MAY in a future 159 version of this document. 160 MUST- This term means the same as MUST. However, we expect at 161 some point that this algorithm will no longer be a MUST in a 162 future document. Although its status will be determined at 163 a later time, it is reasonable to expect that if a future 164 revision of a document alters the status of a MUST- 165 algorithm, it will remain at least a SHOULD or a SHOULD-. 167 Table 1 169 3. Algorithm Selection 171 3.1. DNSKEY Algorithms 173 Recommendations for DNSKEY algorithms 175 +--------+--------------------+----------------+-------------------+ 176 | Number | Mnemonics | DNSSEC Signing | DNSSEC Validation | 177 +--------+--------------------+----------------+-------------------+ 178 | 1 | RSAMD5 | MUST NOT | MUST NOT | 179 | 3 | DSA | MUST NOT | MUST NOT | 180 | 5 | RSASHA1 | MUST- | MUST- | 181 | 6 | DSA-NSEC3-SHA1 | MUST NOT | MUST NOT | 182 | 7 | RSASHA1-NSEC3-SHA1 | MUST- | MUST- | 183 | 8 | RSASHA256 | MUST | MUST | 184 | 10 | RSASHA512 | SHOULD- | MUST | 185 | 12 | ECC-GOST | SHOULD NOT | SHOULD | 186 | 13 | ECDSAP256SHA256 | SHOULD+ | MUST | 187 | 14 | ECDSAP384SHA384 | SHOULD NOT | SHOULD | 188 | TBD | ED25519 | SHOULD+ | SHOULD+ | 189 | TBD | ED448 | SHOULD | SHOULD+ | 190 +--------+--------------------+----------------+-------------------+ 192 Table 2 194 RSAMD5 is not widely deployed and there is an industry-wide trend to 195 deprecate MD5 usage. 197 RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones 198 deploying it are recommended to switch to RSASHA256 as there is an 199 industry-wide trend to deprecate SHA1 usage. RSASHA1 does not 200 support NSEC3. RSASHA1-NSEC3-SHA1 can be used with or without NSEC3. 202 DSA and DSA-NSEC3-SHA1 are not widely deployed and vulnerable to 203 private key compromise when generating signatures using a weak or 204 compromised random number generator. 206 RSASHA512 is at the SHOULD level for DNSSEC Signing because it has 207 not seen wide deployment, but there are some deployments hence DNSSEC 208 Validation MUST implement RSASHA512 to ensure interoperability. 210 ECC-GOST is at the SHOULD NOT level because it has not seen wide 211 deployment and the algorithm has not seen wide scrutiny in the crypto 212 community. 214 ECDSAP256SHA256 and ECDSAP384SHA384 provide more strength for 215 signature size than RSASHA256 and RSASHA512 variants. It is expected 216 ECDSAP256SHA256 will be raised to MUST once it has been deployed more 217 widely for DNSSEC Signing. ECDSAP256SHA256 has seen raise in the 218 deployment, so it's set to MUST level for DNSSEC Validation. 219 ECDSAP384SHA384 offers little over ECDSAP256SHA256 and has not seen 220 wide deployment, so it is at the SHOULD NOT level. 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. Hence we expect 227 that those algorithms will be raised to MUST once they have been 228 deployed more widely. 230 3.2. DS and CDS Algorithms 231 Recommendations for Delegation Signer Digest Algorithms. These also 232 apply to the CDS RRTYPE as specified in [RFC7344] 234 +--------+-----------------+-------------------+-------------------+ 235 | Number | Mnemonics | DNSSEC Delegation | DNSSEC Validation | 236 +--------+-----------------+-------------------+-------------------+ 237 | 0 | NULL (CDS only) | MUST NOT [*] | MUST NOT [*] | 238 | 1 | SHA-1 | SHOULD NOT | MUST- | 239 | 2 | SHA-256 | MUST | MUST | 240 | 3 | GOST R 34.11-94 | MAY | SHOULD | 241 | 4 | SHA-384 | MAY | SHOULD+ | 242 +--------+-----------------+-------------------+-------------------+ 244 [*] - This is a special type of CDS record signaling removal of DS at 245 the parent in [I-D.ietf-dnsop-maintain-ds] 247 Table 3 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, DOI 10.17487/ 312 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, DOI 329 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, DOI 339 10.17487/RFC6605, April 2012, 340 . 342 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 343 Operational Practices, Version 2", RFC 6781, DOI 10.17487/ 344 RFC6781, December 2012, 345 . 347 [RFC6944] Rose, S., "Applicability Statement: DNS Security (DNSSEC) 348 DNSKEY Algorithm Implementation Status", RFC 6944, DOI 349 10.17487/RFC6944, April 2013, 350 . 352 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 353 DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 354 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, DOI 359 10.17487/RFC7583, October 2015, 360 . 362 [I-D.ietf-curdle-dnskey-ed25519] 363 Sury, O. and R. Edmonds, "Ed25519 for DNSSEC", draft-ietf- 364 curdle-dnskey-ed25519-01 (work in progress), February 365 2016. 367 [I-D.ietf-curdle-dnskey-ed448] 368 Sury, O. and R. Edmonds, "Ed448 for DNSSEC", draft-ietf- 369 curdle-dnskey-ed448-00 (work in progress), March 2016. 371 [I-D.ietf-dnsop-maintain-ds] 372 Gu[eth]mundsson, O. and P. Wouters, "Managing DS records 373 from parent via CDS/CDNSKEY", draft-ietf-dnsop-maintain- 374 ds-00 (work in progress), December 2015. 376 [DNSKEY-IANA] 377 , "DNSKEY Algorithms", , . 380 [DS-IANA] , "Delegation Signer Digest Algorithms", , . 383 Authors' Addresses 385 Paul Wouters 386 Red Hat 388 EMail: pwouters@redhat.com 390 Ondrej Sury 391 CZ.NIC 393 EMail: ondrej.sury@nic.cz