idnits 2.17.1 draft-york-dnsop-deploying-dnssec-crypto-algs-03.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 174: '... resolver SHOULD treat the child zon...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2733 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: May 4, 2017 CZ.NIC 6 P. Wouters 7 Red Hat 8 O. Gudmundsson 9 CloudFlare 10 October 31, 2016 12 Observations on Deploying New DNSSEC Cryptographic Algorithms 13 draft-york-dnsop-deploying-dnssec-crypto-algs-03 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 May 4, 2017. 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 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.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.5. Registrars . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.6. DNS Hosting Operators . . . . . . . . . . . . . . . . . . 7 67 2.7. Applications . . . . . . . . . . . . . . . . . . . . . . 7 68 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 72 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 The DNS Security Extensions (DNSSEC), broadly defined in 78 {{?RFC4033}}, {{?RFC4034}} and {{?RFC4035}}, make use of 79 cryptographic algorithms in both the signing of DNS records and the 80 validation of DNSSEC signatures by recursive resolvers. 82 The current list of cryptographic algorithms can be found in the IANA 83 "Domain Name System Security (DNSSEC) Algorithm Numbers" registry 84 located at 85 Algorithms are added to this IANA registry through a process defined 86 in {{?RFC6014}}. Note that {{?RFC6944}} provides some guidance as to 87 which of these algorithms should be implemented and supported. 89 Historically DNSSEC signatures have primarily used cryptographic 90 algorithms based on RSA keys. As deployment of DNSSEC has increased 91 there has been interest in using newer and more secure algorithms, 92 particularly those using elliptic curve cryptography. 93 The ECDSA algorithm {{?RFC6605}} has seen some adoption and two new 94 algorithms are being proposed: Ed25519 and Ed448 . 96 The challenge is that the deployment of a new cryptographic algorithm 97 for DNSSEC is not a simple process. DNSSEC algorithms are used 98 throughout the DNS infrastructure for tasks such as: 100 o Generation of keys ("DNSKEY" record) for signing 102 o Creation of DNSSEC signatures in zone files ("RRSIG") 104 o Usage in a Delegation Signer ("DS") record {{?RFC3658}} for the 105 "chain of trust" connecting back to the root of DNS 107 o Generation of NSEC/NSEC3 responses by authoritative DNS servers 109 o Validation of DNSSEC signatures by DNS resolvers 111 In order for a new cryptographic algorithm to be fully deployed, all 112 aspects of the DNS infrastructure that interact with DNSSEC must be 113 updated to use the new algorithm. 115 This document outlines the current understanding of the components of 116 the DNS infrastructure that need to be updated to deploy a new 117 cryptographic algorithm. 119 It should be noted that DNSSEC is not alone in complexity of 120 deployment. The IAB documented "Guidelines for Cryptographic 121 Algorithm Agility" in {{?RFC7696}} to highlight the importance of 122 this issue. 124 1.1. Terminology 126 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 127 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 128 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 129 . 131 2. Aspects of Deploying New Algorithms 133 For a new cryptographic algorithm to be deployed in DNSSEC, the 134 following aspects of the DNS infrastructure must be updated: 136 o DNS resolvers performing validation 138 o Authoritative DNS servers 140 o Signing software 142 o Registries 143 o Registrars 145 o DNS Hosting Operators 147 o Applications 149 Each of these aspects is discussed in more detail below. 151 2.1. DNS Resolvers Performing Validation 153 DNS recursive resolvers perform "validation" to check the DNSSEC 154 signatures of records received in a DNS query. To validate the 155 signatures, the resolvers need to be able to understand the algorithm 156 used to create the signatures. 158 In the case of a new algorithm, the resolver software needs to be 159 updated. In some cases this could require waiting until an 160 underlying library is updated to support the new algorithm. 162 Once the software is updated, the updates need to be deployed to all 163 resolvers using that software. This can be challenging in cases of 164 customer-premises equipment (CPE) that does not have any mechanism 165 for automatic updating. 167 2.1.1. Resolvers and Unknown Algorithms 169 It should be noted that section 5.2 of {{?RFC4035}} states: 171 "If the resolver does not support any of the algorithms listed in an 172 authenticated DS RRset, then the resolver will not be able to verify 173 the authentication path to the child zone. In this case, the 174 resolver SHOULD treat the child zone as if it were unsigned." 176 This means that signing a zone with a new algorithm that is not 177 widely supported by DNS resolvers would result in the signatures 178 being ignored and the zone treated as unsigned until resolvers were 179 updated to recognize the new algorithm. 181 Note that in at least one 2016 case the resolver software deployed on 182 customer premises by an Internet service provider (ISP) turned out 183 not to be compliant with RFC 4035. Instead of ignoring the 184 signatures using unknown algorithms and treating the zones as 185 unsigned, the validating resolver rejected the signatures and 186 returned a SERVFAIL to the DNS query. This resulted in the ISP 187 turning off DNSSEC validation on the equipment. Further 188 investigation showed that a newer version of the resolver software 189 did correctly support ECDSA, but now all customer premises equipment 190 must be updated to this new version. 192 The point is that it is not safe to assume all resolver software will 193 correctly implement this part of RFC 4035. 195 2.2. Authoritative DNS Servers 197 Authoritative DNS servers serve out signed DNS records. Serving new 198 DNSSEC signing algorithms should not be a problem as a well-written 199 authoritative DNS server implementation should be agnostic to the RR 200 DATA they serve. 202 The one exception is if the new cryptographic algorithms are used in 203 the creation of NSEC/NSEC3 responses. In the case of new NSEC/NSEC3 204 algorithms, the authoritative DNS server software would need to be 205 updated to be able to use the new algorithms. 207 Note that some authoritative server implementations could include 208 DNSSEC signing as part of the server and thus also fall into the 209 "Signing Software" category below. 211 2.3. Signing Software 213 The software performing the signing of the records needs to be 214 updated with the new cryptographic algorithm. 216 User interfaces that allow users to interact with the DNSSEC signing 217 software may also need to be updated to reflect the existence of the 218 new algorithm. 220 Note that the key and signatures with the new algorithm will need to 221 co-exist with the existing key and signatures for some period of 222 time. This will have an impact on the size of the DNS records. 224 [NOTE(OS): Shouldn't we just update the language that requires the 225 resolver to be so strict and finally be done with this requirement? 226 Or just give a recommendation in the paragraph on resolver here?] 228 One issue that has been identified is that not all commonly-used 229 signing software releases include support for an algorithm rollover. 230 This software would need to be updated to support rolling an 231 algorithm before any new algorithms could be deployed. 233 2.4. Registries 235 The registry for a top-level domain (TLD) needs to accept DS records 236 using the new cryptographic algorithm. 238 Observations to date have shown that some registries only accept DS 239 records with certain algorithms. Registry representatives have 240 indicated that they verify the accuracy of DS records to reduce 241 technical support incidents and ensure customers do not mistakenly 242 create any outages. 244 However, this means that registries who perform this level of 245 checking must be able to understand new algorithms in order to 246 successfully verify the DS records. 248 Separately, feedback from registrars has indicated that they do not 249 currently have any mechanism to understand what DNSSEC algorithms a 250 registry can accept. 252 2.5. Registrars 254 Registrars perform a critical role in the DNSSEC "chain of trust" of 255 passing the DS record up to the Registry to ensure that the signed 256 zone can be authenticated from the root of DNS all the way to the 257 zone. 259 If the registrar is also providing the DNS hosting services for a 260 domain, the registrar can easily create the "DS" record from the 261 "DNSKEY" record and pass the DS record up to the registry. 263 However, if the authoritative servers for a domain are not with the 264 registrar, then the registrar needs to provide some mechanism to 265 accept a DS record to pass that up to the registry. Typically this 266 is done through a web interface. 268 An issue is that many registrar web interfaces only allow the input 269 of DS records using a listed set of DNSSEC algorithms. Any new 270 cryptographic algorithms need to be added to the web interface in 271 order to be accepted into the registrar's system. 273 Additionally, in a manner similar to registries, many registrars 274 perform some level of verification on the DS record to ensure it was 275 entered "correctly". To do this verification, the registrar's 276 software needs to understand the algorithm used in the DS record. 277 This requires the software to be updated to support the new 278 algorithm. 280 Note that work is currently underway in {{?I-D.ietf-dnsop-maintain- 281 ds}} to provide an automated mechanism to update the DS records with 282 a registry. If this method becomes widely adopted, registrar web 283 interfaces may no longer be needed. 285 2.6. DNS Hosting Operators 287 DNS hosting operators are entities that are operating the 288 authoritative DNS servers for domains and with DNSSEC are also 289 providing the signing of zones. In many cases they may also be the 290 registrar for domain names, but in other cases they are a separate 291 entity providing DNS services to customers. 293 DNS hosting operators need to update their authoritative DNS server 294 software to understand new cryptographic algorithms, but they also 295 need to update their web interfaces and provisioning software to 296 allow configuration and support of new algorithms. 298 2.7. Applications 300 Beyond the recursive resolvers, authoritative servers, web interfaces 301 and provisioning software, it has been observed that some 302 applications (or "apps"), particularly in the mobile environment, are 303 including their own DNS resolvers within the app itself. These 304 recursive resolvers are used by the app instead of the recursive 305 resolver included with the underlying operating system. These 306 applications that perform DNSSEC validation would need to also be 307 updated to understand a new algorithm. 309 In many cases, it may be that an underlying developer library needs 310 to be updated first. It will then depend upon how long it takes the 311 application developer to pull in the updated library. 313 Outside of applications, these developer libraries are also typically 314 used by recursive resolver software and signing software. 316 3. Conclusion 318 This document provides a view into the steps necessary for the 319 deployment of new cryptographic algorithms in DNSSEC at the time of 320 this publication. In order to more rapidly roll out new DNSSEC 321 algorithms, these steps must be understood and hopefully improved 322 over time. 324 It should be noted that a common theme to emerge from all discussions 325 is a general reluctance to update or change any DNS-related software. 326 "If it isn't broken, don't fix it" is a common refrain. While 327 perhaps understandable from a stability point of view, this attitude 328 creates a challenge for deploying new algorithms. 330 One potential idea suggested during discussions was for some kind of 331 web-based testing tool that could assist people in understanding what 332 algorithms are supported by different servers and sites. 334 It is also quite clear that any deployment of new algorithms for 335 DNSSEC use will take a few years to propagate throughout the 336 infrastructure. This needs to be factored in as new algorithms are 337 proposed. 339 4. IANA Considerations 341 This document does not make any requests of IANA. 343 5. Security Considerations 345 No new security considerations are created by this document. 347 It should be noted that there are security considerations regarding 348 changing DNSSEC algorithms that are mentioned in both {{?RFC6781}} 349 and {{?RFC7583}}. 351 Appendix A. Acknowledgements 353 The information in this document evolved out of several mailing list 354 discussions and also through engagement with participants in the 355 following sessions or events: 357 o DNSSEC Workshop at ICANN 53 (Buenos Aires) 359 o DNSSEC Workshop at ICANN 55 (Marrakech) 361 o Spring 2016 DNS-OARC meeeting (Buenos Aires) 363 o various IETF 95 working groups (Buenos Aires) 365 o Panel session at RIPE 72 (Copenhagen) 367 o DNSSEC Workshop at ICANN 56 (Helsinki) 369 The authors thank the participants of the various sessions for their 370 feedback. 372 Appendix B. Changes 374 NOTE TO RFC EDITOR - Please remove this "Changes" section prior to 375 publication. Thank you. 377 o Revision -03 removed the reference to the location of the ISP in 378 the text added in version -02. 380 o Revision -02 added text to the resolver section about an example 381 where resolver software did not correctly follow RFC 4035 and 382 treat packets with unknown algorithms as unsigned. The markdown 383 source of this I-D was also migrated to the markdown syntax 384 favored by the 'mmark' tool. 386 o Revision -01 adds text about authoritative servers needing an 387 update if the algorithm is for NSEC/NSEC3. Also expands 388 acknowledgements. 390 Authors' Addresses 392 Dan York 393 Internet Society 395 Email: york@isoc.org 397 Ondrej Sury 398 CZ.NIC 400 Email: ondrej.sury@nic.cz 402 Paul Wouters 403 Red Hat 405 Email: pwouters@redhat.com 407 Olafur Gudmundsson 408 CloudFlare 410 Email: olafur+ietf@cloudflare.com