idnits 2.17.1 draft-york-dnsop-deploying-dnssec-crypto-algs-06.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 (October 21, 2018) is 2012 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3658 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 6944 (Obsoleted by RFC 8624) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP D. York 3 Internet-Draft Internet Society 4 Intended status: Informational O. Sury 5 Expires: April 24, 2019 ISC 6 P. Wouters 7 Red Hat 8 O. Gudmundsson 9 CloudFlare 10 October 21, 2018 12 Observations on Deploying New DNSSEC Cryptographic Algorithms 13 draft-york-dnsop-deploying-dnssec-crypto-algs-06 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 April 24, 2019. 40 Copyright Notice 42 Copyright (c) 2018 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 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Aspects of Deploying New Algorithms . . . . . . . . . . . . . 3 60 2.1. DNS Resolvers Performing Validation . . . . . . . . . . . 4 61 2.1.1. Resolvers and Unknown Algorithms . . . . . . . . . . 4 62 2.2. Authoritative DNS Servers . . . . . . . . . . . . . . . . 5 63 2.3. Signing Software . . . . . . . . . . . . . . . . . . . . 5 64 2.3.1. NSEC3 Iterations . . . . . . . . . . . . . . . . . . 5 65 2.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.5. Registrars . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.6. DNS Hosting Operators . . . . . . . . . . . . . . . . . . 7 68 2.7. Applications . . . . . . . . . . . . . . . . . . . . . . 7 69 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 6.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 76 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 The DNS Security Extensions (DNSSEC), broadly defined in [RFC4033], 82 [RFC4034] and [RFC4035], make use of cryptographic algorithms in both 83 the signing of DNS records and the validation of DNSSEC signatures by 84 recursive resolvers. 86 The current list of cryptographic algorithms can be found in the IANA 87 "Domain Name System Security (DNSSEC) Algorithm Numbers" registry 88 located at 89 Algorithms are added to this IANA registry through a process defined 90 in [RFC6014]. Note that [RFC6944] provides some guidance as to which 91 of these algorithms should be implemented and supported. 93 Historically DNSSEC signatures have primarily used cryptographic 94 algorithms based on RSA keys. As deployment of DNSSEC has increased 95 there has been interest in using newer and more secure algorithms, 96 particularly those using elliptic curve cryptography. 98 The ECDSA algorithm [RFC6605] has seen some adoption and a new 99 signing algorithm is now available: Edwards-curve Digital Signature 100 Algorithm (EdDSA) using a choice of two curves, Ed25519 and Ed448, 101 [RFC8080]. 103 The challenge is that the deployment of a new cryptographic algorithm 104 for DNSSEC is not a simple process. DNSSEC algorithms are used 105 throughout the DNS infrastructure for tasks such as: 107 o Generation of keys ("DNSKEY" record) for signing 109 o Creation of DNSSEC signatures in zone files ("RRSIG") 111 o Usage in a Delegation Signer ("DS") record [RFC3658] for the 112 "chain of trust" connecting back to the root of DNS 114 o Generation of NSEC/NSEC3 responses by authoritative DNS servers 116 o Validation of DNSSEC signatures by DNS resolvers 118 In order for a new cryptographic algorithm to be fully deployed, all 119 aspects of the DNS infrastructure that interact with DNSSEC must be 120 updated to use the new algorithm. 122 This document outlines the current understanding of the components of 123 the DNS infrastructure that need to be updated to deploy a new 124 cryptographic algorithm. 126 It should be noted that DNSSEC is not alone in complexity of 127 deployment. The IAB documented "Guidelines for Cryptographic 128 Algorithm Agility" in [RFC7696] to highlight the importance of this 129 issue. 131 1.1. Terminology 133 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 134 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 135 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 136 [RFC2119]. 138 2. Aspects of Deploying New Algorithms 140 For a new cryptographic algorithm to be deployed in DNSSEC, the 141 following aspects of the DNS infrastructure must be updated: 143 o DNS resolvers performing validation 145 o Authoritative DNS servers 146 o Signing software 148 o Registries 150 o Registrars 152 o DNS Hosting Operators 154 o Applications 156 Each of these aspects is discussed in more detail below. 158 2.1. DNS Resolvers Performing Validation 160 DNS recursive resolvers perform "validation" to check the DNSSEC 161 signatures of records received in a DNS query. To validate the 162 signatures, the resolvers need to be able to understand the algorithm 163 used to create the signatures. 165 In the case of a new algorithm, the resolver software needs to be 166 updated. In some cases this could require waiting until an 167 underlying library is updated to support the new algorithm. 169 Once the software is updated, the updates need to be deployed to all 170 resolvers using that software. This can be challenging in cases of 171 customer-premises equipment (CPE) that does not have any mechanism 172 for automatic updating. 174 2.1.1. Resolvers and Unknown Algorithms 176 It should be noted that section 5.2 of [RFC4035] states: 178 "If the resolver does not support any of the algorithms listed in an 179 authenticated DS RRset, then the resolver will not be able to verify 180 the authentication path to the child zone. In this case, the 181 resolver SHOULD treat the child zone as if it were unsigned." 183 This means that signing a zone with a new algorithm that is not 184 widely supported by DNS resolvers would result in the signatures 185 being ignored and the zone treated as unsigned until resolvers were 186 updated to recognize the new algorithm. 188 Note that in at least one 2016 case the resolver software deployed on 189 customer premises by an Internet service provider (ISP) turned out 190 not to be compliant with RFC 4035. Instead of ignoring the 191 signatures using unknown algorithms and treating the zones as 192 unsigned, the validating resolver rejected the signatures and 193 returned a SERVFAIL to the DNS query. This resulted in the ISP 194 turning off DNSSEC validation on the equipment. Further 195 investigation showed that a newer version of the resolver software 196 did correctly support ECDSA, but now all customer premises equipment 197 must be updated to this new version. 199 The point is that it is not safe to assume all resolver software will 200 correctly implement this part of RFC 4035. 202 2.2. Authoritative DNS Servers 204 Authoritative DNS servers serve out signed DNS records. Serving new 205 DNSSEC signing algorithms should not be a problem as a well-written 206 authoritative DNS server implementation should be agnostic to the RR 207 DATA they serve. 209 The one exception is if the new cryptographic algorithms are used in 210 the creation of NSEC/NSEC3 responses. In the case of new NSEC/NSEC3 211 algorithms, the authoritative DNS server software would need to be 212 updated to be able to use the new algorithms. 214 Note that some authoritative server implementations could include 215 DNSSEC signing as part of the server and thus also fall into the 216 "Signing Software" category below. 218 2.3. Signing Software 220 The software performing the signing of the records needs to be 221 updated with the new cryptographic algorithm. 223 User interfaces that allow users to interact with the DNSSEC signing 224 software may also need to be updated to reflect the existence of the 225 new algorithm. 227 Note that the key and signatures with the new algorithm will need to 228 co-exist with the existing key and signatures for some period of 229 time. This will have an impact on the size of the DNS records. 231 One issue that has been identified is that not all commonly-used 232 signing software releases include support for an algorithm rollover. 233 This software would need to be updated to support rolling an 234 algorithm before any new algorithms could be deployed. 236 2.3.1. NSEC3 Iterations 238 [additional text needed] 240 2.4. Registries 242 The registry for a top-level domain (TLD) needs to accept DS records 243 using the new cryptographic algorithm. 245 Observations to date have shown that some registries only accept DS 246 records with certain algorithms. Registry representatives have 247 indicated that they verify the accuracy of DS records to reduce 248 technical support incidents and ensure customers do not mistakenly 249 create any outages. 251 However, this means that registries who perform this level of 252 checking must be able to understand new algorithms in order to 253 successfully verify the DS records. 255 Separately, feedback from registrars has indicated that they do not 256 currently have any mechanism to understand what DNSSEC algorithms a 257 registry can accept. 259 2.5. Registrars 261 Registrars perform a critical role in the DNSSEC "chain of trust" of 262 passing the DS record up to the Registry to ensure that the signed 263 zone can be authenticated from the root of DNS all the way to the 264 zone. 266 If the registrar is also providing the DNS hosting services for a 267 domain, the registrar can easily create the "DS" record from the 268 "DNSKEY" record and pass the DS record up to the registry. 270 However, if the authoritative servers for a domain are not with the 271 registrar, then the registrar needs to provide some mechanism to 272 accept a DS record to pass that up to the registry. Typically this 273 is done through a web interface. 275 An issue is that many registrar web interfaces only allow the input 276 of DS records using a listed set of DNSSEC algorithms. Any new 277 cryptographic algorithms need to be added to the web interface in 278 order to be accepted into the registrar's system. 280 Additionally, in a manner similar to registries, many registrars 281 perform some level of verification on the DS record to ensure it was 282 entered "correctly". To do this verification, the registrar's 283 software needs to understand the algorithm used in the DS record. 284 This requires the software to be updated to support the new 285 algorithm. 287 Note that work has been standardized in [RFC8078] to provide an 288 automated mechanism to update the DS records with a registry. If 289 this method becomes widely adopted, registrar web interfaces may no 290 longer be needed. 292 2.6. DNS Hosting Operators 294 DNS hosting operators are entities that are operating the 295 authoritative DNS servers for domains and with DNSSEC are also 296 providing the signing of zones. In many cases they may also be the 297 registrar for domain names, but in other cases they are a separate 298 entity providing DNS services to customers. 300 DNS hosting operators need to update their authoritative DNS server 301 software to understand new cryptographic algorithms, but they also 302 need to update their web interfaces and provisioning software to 303 allow configuration and support of new algorithms. 305 2.7. Applications 307 Beyond the recursive resolvers, authoritative servers, web interfaces 308 and provisioning software, it has been observed that some 309 applications (or "apps"), particularly in the mobile environment, are 310 including their own DNS resolvers within the app itself. These 311 recursive resolvers are used by the app instead of the recursive 312 resolver included with the underlying operating system. These 313 applications that perform DNSSEC validation would need to also be 314 updated to understand a new algorithm. 316 In many cases, it may be that an underlying developer library needs 317 to be updated first. It will then depend upon how long it takes the 318 application developer to pull in the updated library. 320 Outside of applications, these developer libraries are also typically 321 used by recursive resolver software and signing software. 323 3. Conclusion 325 This document provides a view into the steps necessary for the 326 deployment of new cryptographic algorithms in DNSSEC at the time of 327 this publication. In order to more rapidly roll out new DNSSEC 328 algorithms, these steps must be understood and hopefully improved 329 over time. 331 It should be noted that a common theme to emerge from all discussions 332 is a general reluctance to update or change any DNS-related software. 333 "If it isn't broken, don't fix it" is a common refrain. While 334 perhaps understandable from a stability point of view, this attitude 335 creates a challenge for deploying new algorithms. 337 One potential idea suggested during discussions was for some kind of 338 web-based testing tool that could assist people in understanding what 339 algorithms are supported by different servers and sites. 341 It is also quite clear that any deployment of new algorithms for 342 DNSSEC use will take a few years to propagate throughout the 343 infrastructure. This needs to be factored in as new algorithms are 344 proposed. 346 4. IANA Considerations 348 This document does not make any requests of IANA. 350 5. Security Considerations 352 No new security considerations are created by this document. 354 It should be noted that there are security considerations regarding 355 changing DNSSEC algorithms that are mentioned in both [RFC6781] and 356 [RFC7583]. 358 6. References 360 6.1. Normative References 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, 364 DOI 10.17487/RFC2119, March 1997, . 367 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 368 Rose, "DNS Security Introduction and Requirements", 369 RFC 4033, DOI 10.17487/RFC4033, March 2005, 370 . 372 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 373 Rose, "Resource Records for the DNS Security Extensions", 374 RFC 4034, DOI 10.17487/RFC4034, March 2005, 375 . 377 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 378 Rose, "Protocol Modifications for the DNS Security 379 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 380 . 382 6.2. Informative References 384 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record 385 (RR)", RFC 3658, DOI 10.17487/RFC3658, December 2003, 386 . 388 [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier 389 Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014, 390 November 2010, . 392 [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital 393 Signature Algorithm (DSA) for DNSSEC", RFC 6605, 394 DOI 10.17487/RFC6605, April 2012, . 397 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 398 Operational Practices, Version 2", RFC 6781, 399 DOI 10.17487/RFC6781, December 2012, . 402 [RFC6944] Rose, S., "Applicability Statement: DNS Security (DNSSEC) 403 DNSKEY Algorithm Implementation Status", RFC 6944, 404 DOI 10.17487/RFC6944, April 2013, . 407 [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking, 408 "DNSSEC Key Rollover Timing Considerations", RFC 7583, 409 DOI 10.17487/RFC7583, October 2015, . 412 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 413 Agility and Selecting Mandatory-to-Implement Algorithms", 414 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 415 . 417 [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from 418 the Parent via CDS/CDNSKEY", RFC 8078, 419 DOI 10.17487/RFC8078, March 2017, . 422 [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security 423 Algorithm (EdDSA) for DNSSEC", RFC 8080, 424 DOI 10.17487/RFC8080, February 2017, . 427 Appendix A. Acknowledgements 429 The information in this document evolved out of several mailing list 430 discussions and also through engagement with participants in the 431 following sessions or events: 433 o DNSSEC Workshop at ICANN 53 (Buenos Aires) 435 o DNSSEC Workshop at ICANN 55 (Marrakech) 437 o Spring 2016 DNS-OARC meeeting (Buenos Aires) 439 o various IETF 95 working groups (Buenos Aires) 441 o Panel session at RIPE 72 (Copenhagen) 443 o DNSSEC Workshop at ICANN 56 (Helsinki) 445 The authors thank the participants of the various sessions for their 446 feedback. 448 Appendix B. Changes 450 NOTE TO RFC EDITOR - Please remove this "Changes" section prior to 451 publication. Thank you. 453 o Revision -06 added in references to RFCs 8080 and 8078 and updated 454 Ondrej Sury's affiliation to ISC. 456 o Revision -05 corrected typos around two other references that did 457 not appear in -04. 459 o Revision -04 corrected the references which did not appear in -03 460 due to an error in the markdown source. 462 o Revision -03 removed the reference to the location of the ISP in 463 the text added in version -02. 465 o Revision -02 added text to the resolver section about an example 466 where resolver software did not correctly follow RFC 4035 and 467 treat packets with unknown algorithms as unsigned. The markdown 468 source of this I-D was also migrated to the markdown syntax 469 favored by the 'mmark' tool. 471 o Revision -01 adds text about authoritative servers needing an 472 update if the algorithm is for NSEC/NSEC3. Also expands 473 acknowledgements. 475 Authors' Addresses 477 Dan York 478 Internet Society 480 Email: york@isoc.org 481 URI: https://www.internetsociety.org/ 483 Ondrej Sury 484 ISC 486 Email: ondrej@isc.org 488 Paul Wouters 489 Red Hat 491 Email: pwouters@redhat.com 493 Olafur Gudmundsson 494 CloudFlare 496 Email: olafur+ietf@cloudflare.com