idnits 2.17.00 (12 Aug 2021) /tmp/idnits27915/draft-wouters-sury-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 17, 2016) is 2255 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 372, but no explicit reference was found in the text == Outdated reference: draft-ietf-dnsop-maintain-ds has been published as RFC 8078 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop P. Wouters 3 Internet-Draft Red Hat 4 Intended status: Standards Track O. Sury 5 Expires: September 18, 2016 CZ.NIC 6 March 17, 2016 8 Algorithm Implementation Requirements and Usage Guidance for DNSSEC 9 draft-wouters-sury-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. 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 18, 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. 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 | SHOULD | 186 | 13 | ECDSAP256SHA256 | SHOULD+ | MUST | 187 | 14 | ECDSAP384SHA384 | SHOULD+ | 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 level because it has not seen wide 211 deployment. 213 ECDSAP256SHA256 and ECDSAP384SHA384 provide more strength for 214 signature size than RSASHA256 and RSASHA512 variants. It is expected 215 to be raised to MUST once they have been deployed more widely for 216 DNSSEC Signing. ECDSAP256SHA256 has seen raise in the deployment, so 217 it's set to MUST level for DNSSEC Validation. 219 ED25519 and ED448 uses Edwards-curve Digital Security Algorithm 220 (EdDSA). There are three main advantages of the EdDSA algorithm: It 221 does not require the use of a unique random number for each 222 signature, there are no padding or truncation issues as with ECDSA, 223 and it is more resilient to side-channel attacks. Hence we expect 224 that those algorithms will be raised to MUST once they have been 225 deployed more widely. 227 3.2. DS and CDS Algorithms 229 Recommendations for Delegation Signer Digest Algorithms. These also 230 apply to the CDS RRTYPE as specified in [RFC7344] 231 +--------+-----------------+-------------------+-------------------+ 232 | Number | Mnemonics | DNSSEC Delegation | DNSSEC Validation | 233 +--------+-----------------+-------------------+-------------------+ 234 | 0 | NULL (CDS only) | MUST NOT [*] | MUST NOT [*] | 235 | 1 | SHA-1 | SHOULD NOT | MUST- | 236 | 2 | SHA-256 | MUST | MUST | 237 | 3 | GOST R 34.11-94 | MAY | SHOULD | 238 | 4 | SHA-384 | MAY | SHOULD+ | 239 +--------+-----------------+-------------------+-------------------+ 241 [*] - This is a special type of CDS record signaling removal of DS at 242 the parent in [I-D.ietf-dnsop-maintain-ds] 244 Table 3 246 NULL is a special case, see [I-D.ietf-dnsop-maintain-ds] 248 SHA-1 is in wide use for DS records, but its use is discouraged as it 249 is an aging algorithm. Users of SHA-1 SHOULD upgrade to SHA-256. 251 SHA-256 is in wide use and considered strong. 253 GOST R 34.11-94 is not in wide use. It is still recommended to be 254 supported in validators so that adoption can increase. 256 SHA-384 is not in wide use. It is still recommended to be supported 257 in validators so that adoption can increase. 259 4. Security Considerations 261 The security of cryptographic-based systems depends on both the 262 strength of the cryptographic algorithms chosen and the strength of 263 the keys used with those algorithms. The security also depends on 264 the engineering of the protocol used by the system to ensure that 265 there are no non-cryptographic ways to bypass the security of the 266 overall system. 268 This document concerns itself with the selection of cryptographic 269 algorithms for the use of DNSSEC, specifically with the selection of 270 "mandatory-to-implement" algorithms. The algorithms identified in 271 this document as "MUST implement" or "SHOULD implement" are not known 272 to be broken at the current time, and cryptographic research so far 273 leads us to believe that they will likely remain secure into the 274 foreseeable future. However, this isn't necessarily forever and it 275 is expected that new revisions of this document will be issued from 276 time to time to reflect the current best practice in this area. 278 Retiring an algorithm too soon would result in a signed zone with 279 such an algorithm to be downgraded to the equivalent of an unsigned 280 zone. Therefore, algorithm deprecation must be done very slowly and 281 only after careful consideration and measurements of its use. 283 5. Operational Considerations 285 DNSKEY algorithm rollover in a live zone is a complex process. See 286 [RFC6781] and [RFC7583] for guidelines on how to perform algorithm 287 rollovers. 289 6. IANA Considerations 291 This document makes no requests of IANA. 293 7. Acknowledgements 295 This document borrows text from RFC 4307 by Jeffrey I. Schiller of 296 the Massachusetts Institute of Technology (MIT) and the 4307bis 297 document by Yoav Nir, Tero Kivinen, Paul Wouters and Daniel Migault. 298 Much of the original text has been copied verbatim. 300 We wish to thank Olafur Gudmundsson and Paul Hoffman for their 301 imminent feedback. 303 8. References 305 8.1. Normative References 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 309 RFC2119, March 1997, 310 . 312 8.2. Informative References 314 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 315 Rose, "Resource Records for the DNS Security Extensions", 316 RFC 4034, DOI 10.17487/RFC4034, March 2005, 317 . 319 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 320 Security (DNSSEC) Hashed Authenticated Denial of 321 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 322 . 324 [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY 325 and RRSIG Resource Records for DNSSEC", RFC 5702, DOI 326 10.17487/RFC5702, October 2009, 327 . 329 [RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of 330 GOST Signature Algorithms in DNSKEY and RRSIG Resource 331 Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July 332 2010, . 334 [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital 335 Signature Algorithm (DSA) for DNSSEC", RFC 6605, DOI 336 10.17487/RFC6605, April 2012, 337 . 339 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 340 Operational Practices, Version 2", RFC 6781, DOI 10.17487/ 341 RFC6781, December 2012, 342 . 344 [RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating 345 DNSSEC Delegation Trust Maintenance", RFC 7344, DOI 346 10.17487/RFC7344, September 2014, 347 . 349 [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, 350 "DNSSEC Key Rollover Timing Considerations", RFC 7583, DOI 351 10.17487/RFC7583, October 2015, 352 . 354 [I-D.ietf-curdle-dnskey-ed25519] 355 Sury, O. and R. Edmonds, "Ed25519 for DNSSEC", draft-ietf- 356 curdle-dnskey-ed25519-01 (work in progress), February 357 2016. 359 [I-D.ietf-curdle-dnskey-ed448] 360 Sury, O. and R. Edmonds, "Ed448 for DNSSEC", draft-ietf- 361 curdle-dnskey-ed448-00 (work in progress), March 2016. 363 [I-D.ietf-dnsop-maintain-ds] 364 Gu[eth]mundsson, O. and P. Wouters, "Managing DS records 365 from parent via CDS/CDNSKEY", draft-ietf-dnsop-maintain- 366 ds-00 (work in progress), December 2015. 368 [DNSKEY-IANA] 369 , "DNSKEY Algorithms", , . 372 [DS-IANA] , "Delegation Signer Digest Algorithms", , . 375 Authors' Addresses 377 Paul Wouters 378 Red Hat 380 EMail: pwouters@redhat.com 382 Ondrej Sury 383 CZ.NIC 385 EMail: ondrej.sury@nic.cz