idnits 2.17.00 (12 Aug 2021) /tmp/idnits4931/draft-york-dnsop-deploying-dnssec-crypto-algs-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 21, 2016) is 2252 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6944 (Obsoleted by RFC 8624) -- Obsolete informational reference (is this intentional?): RFC 3658 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == 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 Working Group D. York 3 Internet-Draft Internet Society 4 Intended status: Informational O. Sury 5 Expires: September 22, 2016 CZ.NIC 6 P. Wouters 7 Red Hat 8 O. Gudmundsson 9 CloudFlare 10 March 21, 2016 12 Observations on Deploying New DNSSEC Cryptographic Algorithms 13 draft-york-dnsop-deploying-dnssec-crypto-algs-00 15 Abstract 17 As new cryptographic algorithms are developed for use in DNSSEC 18 signing and validation, this document captures the steps needed for 19 new algorithms to be deployed and enter general usage. The intent is 20 to ensure a common understanding of the typical deployment process 21 and potentially identify opportunities for improvement of operations. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 22, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 1. Introduction 57 The DNS Security Extensions (DNSSEC), broadly defined in [RFC4033], 58 [RFC4034] and [RFC4035], make use of cryptographic algorithms in both 59 the signing of DNS records and the validation of DNSSEC signatures by 60 recursive resolvers. 62 The current list of cryptographic algorithms can be found in the IANA 63 "Domain Name System Security (DNSSEC) Algorithm Numbers" registry 64 located at http://www.iana.org/assignments/dns-sec-alg-numbers/ 65 Algorithms are added to this IANA registry through a process defined 66 in [RFC6014]. Note that [RFC6944] provides some guidance as to which 67 of these algorithms should be implemented and supported. 69 Historically DNSSEC signatures have primarily used cryptographic 70 algorithms based on RSA keys. As deployment of DNSSEC has increased 71 there has been interest in using newer and more secure algorithms, 72 particularly those using elliptic curve cryptography. 73 The ECDSA algorithm [RFC6605] has seen some adoption and two new 74 algorithms are being proposed: Ed25519 75 [I-D.ietf-curdle-dnskey-ed25519] and Ed448 76 [I-D.ietf-curdle-dnskey-ed448]. 78 The challenge is that the deployment of a new cryptographic algorithm 79 for DNSSEC is not a simple process. DNSSEC algorithms are used 80 throughout the DNS infrastructure for tasks such as: 82 o Generation of keys ("DNSKEY" record) for signing 84 o Creation of DNSSEC signatures in zone files ("RRSIG") 86 o Usage in a Delegation Signer ("DS") record [RFC3658] for the 87 "chain of trust" connecting back to the root of DNS 89 o Validation of DNSSEC signatures by DNS resolvers 91 In order for a new cryptographic algorithm to be fully deployed, all 92 aspects of the DNS infrastructure that interact with DNSSEC must be 93 updated to use the new algorithm. 95 This document outlines the current understanding of the components of 96 the DNS infrastructure that need to be updated to deploy a new 97 cryptographic algorithm. 99 It should be noted that DNSSEC is not alone in complexity of 100 deployment. The IAB documented "Guidelines for Cryptographic 101 Algorithm Agility" in [RFC7696] to highlight the importance of this 102 issue. 104 1.1. Terminology 106 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 107 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 108 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 109 [RFC2119]. 111 2. Aspects of Deploying New Algorithms 113 For a new cryptographic algorithm to be deployed in DNSSEC, the 114 following aspects of the DNS infrastructure must be updated: 116 o DNS resolvers performing validation 118 o Authoritative DNS servers 120 o Signing software 122 o Registries 124 o Registrars 126 o DNS Hosting Operators 128 o Applications 130 Each of these aspects is discussed in more detail below. 132 2.1. DNS Resolvers Performing Validation 134 DNS recursive resolvers perform "validation" to check the DNSSEC 135 signatures of records received in a DNS query. To validate the 136 signatures, the resolvers need to be able to understand the algorithm 137 used to create the signatures. 139 In the case of a new algorithm, the resolver software needs to be 140 updated. In some cases this could require waiting until an 141 underlying library is updated to support the new algorithm. 143 Once the software is updated, the updates need to be deployed to all 144 resolvers using that software. This can be challenging in cases of 145 customer-premises equipment (CPE) that does not have any mechanism 146 for automatic updating. 148 2.1.1. Resolvers and Unknown Algorithms 150 It should be noted that section 5.2 of [RFC4035] states: 152 "If the resolver does not support any of the algorithms listed in an 153 authenticated DS RRset, then the resolver will not be able to verify 154 the authentication path to the child zone. In this case, the 155 resolver SHOULD treat the child zone as if it were unsigned." 157 This means that signing a zone with a new algorithm that is not 158 widely supported by DNS resolvers would result in the signatures 159 being ignored and the zone treated as unsigned until resolvers were 160 updated to recognize the new algorithm. 162 2.2. Authoritative DNS Servers 164 Authoritative DNS servers serve out signed DNS records. Serving new 165 DNSSEC signing algorithms should not be a problem as a well-written 166 authoritative DNS server implementation should be agnostic to the RR 167 DATA they serve. Note that some authoritative server implementations 168 could include DNSSEC signing as part of the server and thus also fall 169 into the "Signing Software" category below. 171 [NOTE(OS): Do we also address new NSEC/NSEC3 hashing algorithms? 172 Because that would require update in the authoritative DNS server.] 174 2.3. Signing Software 176 The software performing the signing of the records needs to be 177 updated with the new cryptographic algorithm. 179 User interfaces that allow users to interact with the DNSSEC signing 180 software may also need to be updated to reflect the existence of the 181 new algorithm. 183 Note that the key and signatures with the new algorithm will need to 184 co-exist with the existing key and signatures for some period of 185 time, which would have some impact on the size of the DNS records. 187 [NOTE(OS): Shouldn't we just update the language that requires the 188 resolver to be so strict and finally be done with this requirement? 189 Or just give a recommendation in the paragraph on resolver here?] 191 [NOTE(DY): I just noticed that "Signing software" or "Signers" does 192 not exist in the "DNS Terminology draft at 193 https://tools.ietf.org/html/rfc7719 ] 195 2.4. Registries 197 The registry for a top-level domain (TLD) needs to accept DS records 198 using the new cryptographic algorithm. 200 Observations to date have shown that some registries only accept DS 201 records with certain algorithms. Registry representatives have 202 indicated that they verify the accuracy of DS records to reduce 203 technical support incidents and ensure customers do not mistakenly 204 create any outages. 206 However, this means that registries who perform this level of 207 checking must be able to understand new algorithms in order to 208 successfully verify the DS records. 210 Separately, feedback from registrars has indicated that they do not 211 currently have any mechanism to understand what DNSSEC algorithms a 212 registry can accept. 214 2.5. Registrars 216 Registrars perform a critical role in the DNSSEC "chain of trust" of 217 passing the DS record up to the Registry to ensure that the signed 218 zone can be authenticated from the root of DNS all the way to the 219 zone. 221 If the registrar is also providing the DNS hosting services for a 222 domain, the registrar can easily create the "DS" record from the 223 "DNSKEY" record and pass the DS record up to the registry. 225 However, if the authoritative servers for a domain are not with the 226 registrar, then the registrar needs to provide some mechanism to 227 accept a DS record to pass that up to the registry. Typically this 228 is done through a web interface. 230 An issue is that many registrar web interfaces only allow the input 231 of DS records using a listed set of DNSSEC algorithms. Any new 232 cryptographic algorithms need to be added to the web interface in 233 order to be accepted into the registrar's system. 235 Additionally, in a manner similar to registries, many registrars 236 perform some level of verification on the DS record to ensure it was 237 entered "correctly". To do this verification, the registrar's 238 software needs to understand the algorithm used in the DS record. 240 This requires the software to be updated to support the new 241 algorithm. 243 Note that work is currently underway in [I-D.ietf-dnsop-maintain-ds] 244 to provide an automated mechanism to update the DS records with a 245 registry. If this method becomes widely adopted, registrar web 246 interfaces will no longer be needed. 248 2.6. DNS Hosting Operators 250 DNS hosting operators are entities that are operating the 251 authoritative DNS servers for domains and with DNSSEC are also 252 providing the signing of zones. In many cases they may also be the 253 registrar for domain names, but in other cases they are a separate 254 entity providing DNS services to customers. 256 DNS hosting operators need to update their authoritative DNS server 257 software to understand new cryptographic algorithms, but they also 258 need to update their web interfaces and provisioning software to 259 allow configuration and support of new algorithms. 261 2.7. Applications 263 Beyond the recursive resolvers, authoritative servers, web interfaces 264 and provisioning software, it has been observed that some 265 applications (or "apps"), particularly in the mobile environment, are 266 including their own DNS resolvers within the app itself. These 267 recursive resolvers are used by the app instead of the recursive 268 resolver included with the underlying operating system. These 269 applications that perform DNSSEC validation would need to also be 270 updated to understand a new algorithm. 272 In many cases, it may be that an underlying developer library needs 273 to be updated first. It will then depend upon how long it takes the 274 application developer to pull in the updated library. 276 Outside of applications, these developer libraries are also typically 277 used by recursive resolver software and signing software. 279 3. Conclusion 281 This document provides a view into the steps necessary for the 282 deployment of new cryptographic algorithms in DNSSEC at the time of 283 this publication. In order to more rapidly roll out new DNSSEC 284 algorithms, these steps must be understood and hopefully improved 285 over time. 287 4. IANA Considerations 289 This document does not make any requests of IANA. 291 5. Security Considerations 293 No new security considerations are created by this document. 295 It should be noted that there are security considerations regarding 296 changing DNSSEC algorithms that are mentioned in both [RFC6781] and 297 [RFC7583]. 299 6. Acknowledgements 301 The information in this document evolved out of several mailing list 302 discussions and also through engagement with participants in the 303 DNSSEC Workshop sessions at ICANN 53 (Buenos Aires) and ICANN 55 304 (Marrakech). 306 7. References 308 7.1. Normative References 310 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 311 Requirement Levels", BCP 14, RFC 2119, March 1997. 313 7.2. Informative References 315 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 316 Rose, "DNS Security Introduction and Requirements", RFC 317 4033, DOI 10.17487/RFC4033, March 2005, 318 . 320 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 321 Rose, "Resource Records for the DNS Security Extensions", 322 RFC 4034, DOI 10.17487/RFC4034, March 2005, 323 . 325 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 326 Rose, "Protocol Modifications for the DNS Security 327 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 328 . 330 [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier 331 Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014, 332 November 2010, . 334 [RFC6944] Rose, S., "Applicability Statement: DNS Security (DNSSEC) 335 DNSKEY Algorithm Implementation Status", RFC 6944, DOI 336 10.17487/RFC6944, April 2013, 337 . 339 [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital 340 Signature Algorithm (DSA) for DNSSEC", RFC 6605, DOI 341 10.17487/RFC6605, April 2012, 342 . 344 [I-D.ietf-curdle-dnskey-ed25519] 345 Sury, O. and R. Edmonds, "Ed25519 for DNSSEC", draft-ietf- 346 curdle-dnskey-ed25519-01 (work in progress), February 347 2016. 349 [I-D.ietf-curdle-dnskey-ed448] 350 Sury, O. and R. Edmonds, "Ed448 for DNSSEC", draft-ietf- 351 curdle-dnskey-ed448-00 (work in progress), March 2016. 353 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record 354 (RR)", RFC 3658, DOI 10.17487/RFC3658, December 2003, 355 . 357 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 358 Agility and Selecting Mandatory-to-Implement Algorithms", 359 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 360 . 362 [I-D.ietf-dnsop-maintain-ds] 363 Gu[eth]mundsson, O. and P. Wouters, "Managing DS records 364 from parent via CDS/CDNSKEY", draft-ietf-dnsop-maintain- 365 ds-01 (work in progress), March 2016. 367 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 368 Operational Practices, Version 2", RFC 6781, DOI 10.17487/ 369 RFC6781, December 2012, 370 . 372 [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, 373 "DNSSEC Key Rollover Timing Considerations", RFC 7583, DOI 374 10.17487/RFC7583, October 2015, 375 . 377 Authors' Addresses 378 Dan York 379 Internet Society 381 Email: york@isoc.org 383 Ondrej Sury 384 CZ.NIC 386 Email: ondrej.sury@nic.cz 388 Paul Wouters 389 Red Hat 391 Email: pwouters@redhat.com 393 Olafur Gudmundsson 394 CloudFlare 396 Email: olafur+ietf@cloudflare.com