idnits 2.17.1
draft-york-dnsop-deploying-dnssec-crypto-algs-05.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 (July 3, 2017) is 2490 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: January 4, 2018 CZ.NIC
6 P. Wouters
7 Red Hat
8 O. Gudmundsson
9 CloudFlare
10 July 3, 2017
12 Observations on Deploying New DNSSEC Cryptographic Algorithms
13 draft-york-dnsop-deploying-dnssec-crypto-algs-05
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 January 4, 2018.
40 Copyright Notice
42 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . 7
66 2.5. Registrars . . . . . . . . . . . . . . . . . . . . . . . 7
67 2.6. DNS Hosting Operators . . . . . . . . . . . . . . . . . . 8
68 2.7. Applications . . . . . . . . . . . . . . . . . . . . . . 8
69 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 8
70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
73 6.1. Normative References . . . . . . . . . . . . . . . . . . 9
74 6.2. Informative References . . . . . . . . . . . . . . . . . 10
75 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
76 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 11
77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 the more
99 recent [RFC8080] specifies the Edwards-curve Digital Signature
100 Algorithm (EdDSA) using a choice of two curves, Ed25519 and Ed448.
102 The challenge is that the deployment of a new cryptographic algorithm
103 for DNSSEC is not a simple process. DNSSEC algorithms are used
104 throughout the DNS infrastructure for tasks such as:
106 o Generation of keys ("DNSKEY" record) for signing
108 o Creation of DNSSEC signatures in zone files ("RRSIG")
110 o Usage in a Delegation Signer ("DS") record [RFC3658] for the
111 "chain of trust" connecting back to the root of DNS
113 o Generation of NSEC/NSEC3 responses by authoritative DNS servers
115 o Validation of DNSSEC signatures by DNS resolvers
117 In order for a new cryptographic algorithm to be fully deployed, all
118 aspects of the DNS infrastructure that interact with DNSSEC must be
119 updated to use the new algorithm.
121 This document outlines the current understanding of the components of
122 the DNS infrastructure that need to be updated to deploy a new
123 cryptographic algorithm.
125 It should be noted that DNSSEC is not alone in complexity of
126 deployment. The IAB documented "Guidelines for Cryptographic
127 Algorithm Agility" in [RFC7696] to highlight the importance of this
128 issue.
130 1.1. Terminology
132 In this document, the key words "MUST", "MUST NOT", "REQUIRED",
133 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
134 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
135 [RFC2119].
137 2. Aspects of Deploying New Algorithms
139 For a new cryptographic algorithm to be deployed in DNSSEC, the
140 following aspects of the DNS infrastructure must be updated:
142 o DNS resolvers performing validation
144 o Authoritative DNS servers
145 o Signing software
147 o Registries
149 o Registrars
151 o DNS Hosting Operators
153 o Applications
155 Each of these aspects is discussed in more detail below.
157 2.1. DNS Resolvers Performing Validation
159 DNS recursive resolvers perform "validation" to check the DNSSEC
160 signatures of records received in a DNS query. To validate the
161 signatures, the resolvers need to be able to understand the algorithm
162 used to create the signatures.
164 In the case of a new algorithm, the resolver software needs to be
165 updated. In some cases this could require waiting until an
166 underlying library is updated to support the new algorithm.
168 Once the software is updated, the updates need to be deployed to all
169 resolvers using that software. This can be challenging in cases of
170 customer-premises equipment (CPE) that does not have any mechanism
171 for automatic updating.
173 2.1.1. Resolvers and Unknown Algorithms
175 It should be noted that section 5.2 of [RFC4035] states:
177 "If the resolver does not support any of the algorithms listed
178 in an authenticated DS RRset, then the resolver will not be
179 able to verify the authentication path to the child zone.
180 In this case, the resolver SHOULD treat the child zone as
181 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 Implementation experience has shown that the [RFC5155] NSEC3
239 iteration count limits are poorly understood and are fragile in the
240 context of adoption of elliptic curve(EC)-based algorithms.
242 A simple design would have constrained the iteration count only by
243 the bit width of the iteration count field (perhaps 12 bits for up
244 4096 iterations), with all representable values supported by both
245 signers and resolvers. Instead, the iteration count limit was made
246 dependent on key size. When the original text of Section 10.3 of
247 [RFC5155] was written, the only commonly used DNSSEC key algorithms
248 were RSA and DSA. These had similar key sizes with comparable
249 security, with DSA slower than RSA. A decision was made to specify
250 iteration count limits roughly commensurate with the cost of RSA
251 operations for a given key size, and to use the same limits for both
252 RSA and DSA. The essential features of the specification are:
254 The limits, therefore, are based on the size of the smallest
255 zone signing key, rounded up to the nearest table value (or
256 rounded down if the key is larger than the largest table
257 value).
258 ...
259 Therefore the values in the table MUST be used independent of
260 the key algorithm.
262 While the specified key-size-dependent limits made some sense for
263 both RSA and DSA, they map poorly to elliptic-curve-based (EC) DNSSEC
264 algorithms, which only use keys shorter than 1024 bits.
265 Nevertheless, popular DNS resolvers apply the specified table of
266 limits to EC algorithms, and so zones with EC keys need to cap their
267 NSEC3 iteration counts at 150.
269 This requirement is surprising to some operators migrating from RSA
270 to EC keys. They continue to use iteration counts that work for RSA-
271 2048, but which exceed the 150 limit for the smaller EC keys. This
272 renders denial-of-existence "Insecure" for the zones in question.
274 Some signer implementations allow maximums that are higher than the
275 specified key-size-dependent limits, resulting again in resolvers
276 possibly returning these answers as "Insecure".
278 To avoid surprises, such as downgrade attacks against "SMTP Security
279 via Opportunistic DANE TLS" [RFC7672], DNSSEC signers should not use
280 an iteration count higher than 150: such iteration counts are prone
281 to fail when configuration changes introduce new algorithms.
283 Similarly, resolvers should not support configurations with iteration
284 count limits below 150, as lower limits may lead to insecure denial
285 of existence, even for compliant zones.
287 2.4. Registries
289 The registry for a top-level domain (TLD) needs to accept DS records
290 using the new cryptographic algorithm.
292 Observations to date have shown that some registries only accept DS
293 records with certain algorithms. Registry representatives have
294 indicated that they verify the accuracy of DS records to reduce
295 technical support incidents and ensure customers do not mistakenly
296 create any outages.
298 However, this means that registries who perform this level of
299 checking must be able to understand new algorithms in order to
300 successfully verify the DS records.
302 Separately, feedback from registrars has indicated that they do not
303 currently have any mechanism to understand what DNSSEC algorithms a
304 registry can accept.
306 2.5. Registrars
308 Registrars perform a critical role in the DNSSEC "chain of trust" of
309 passing the DS record up to the Registry to ensure that the signed
310 zone can be authenticated from the root of DNS all the way to the
311 zone.
313 If the registrar is also providing the DNS hosting services for a
314 domain, the registrar can easily create the "DS" record from the
315 "DNSKEY" record and pass the DS record up to the registry.
317 However, if the authoritative servers for a domain are not with the
318 registrar, then the registrar needs to provide some mechanism to
319 accept a DS record to pass that up to the registry. Typically this
320 is done through a web interface.
322 An issue is that many registrar web interfaces only allow the input
323 of DS records using a listed set of DNSSEC algorithms. Any new
324 cryptographic algorithms need to be added to the web interface in
325 order to be accepted into the registrar's system.
327 Additionally, in a manner similar to registries, many registrars
328 perform some level of verification on the DS record to ensure it was
329 entered "correctly". To do this verification, the registrar's
330 software needs to understand the algorithm used in the DS record.
331 This requires the software to be updated to support the new
332 algorithm.
334 Note that [RFC8078] defines an automated mechanism to update the DS
335 records with a registry. If this method becomes widely adopted,
336 registrar web interfaces may no longer be needed.
338 2.6. DNS Hosting Operators
340 DNS hosting operators are entities that are operating the
341 authoritative DNS servers for domains and with DNSSEC are also
342 providing the signing of zones. In many cases they may also be the
343 registrar for domain names, but in other cases they are a separate
344 entity providing DNS services to customers.
346 DNS hosting operators need to update their authoritative DNS server
347 software to understand new cryptographic algorithms, but they also
348 need to update their web interfaces and provisioning software to
349 allow configuration and support of new algorithms.
351 2.7. Applications
353 Beyond the recursive resolvers, authoritative servers, web interfaces
354 and provisioning software, it has been observed that some
355 applications (or "apps"), particularly in the mobile environment, are
356 including their own DNS resolvers within the app itself. These
357 recursive resolvers are used by the app instead of the recursive
358 resolver included with the underlying operating system. These
359 applications that perform DNSSEC validation would need to also be
360 updated to understand a new algorithm.
362 In many cases, it may be that an underlying developer library needs
363 to be updated first. It will then depend upon how long it takes the
364 application developer to pull in the updated library.
366 Outside of applications, these developer libraries are also typically
367 used by recursive resolver software and signing software.
369 3. Conclusion
371 This document provides a view into the steps necessary for the
372 deployment of new cryptographic algorithms in DNSSEC at the time of
373 this publication. In order to more rapidly roll out new DNSSEC
374 algorithms, these steps must be understood and hopefully improved
375 over time.
377 It should be noted that a common theme to emerge from all discussions
378 is a general reluctance to update or change any DNS-related software.
379 "If it isn't broken, don't fix it" is a common refrain. While
380 perhaps understandable from a stability point of view, this attitude
381 creates a challenge for deploying new algorithms.
383 One potential idea suggested during discussions was for some kind of
384 web-based testing tool that could assist people in understanding what
385 algorithms are supported by different servers and sites.
387 It is also quite clear that any deployment of new algorithms for
388 DNSSEC use will take a few years to propagate throughout the
389 infrastructure. This needs to be factored in as new algorithms are
390 proposed.
392 4. IANA Considerations
394 This document does not make any requests of IANA.
396 5. Security Considerations
398 No new security considerations are created by this document.
400 It should be noted that there are security considerations regarding
401 changing DNSSEC algorithms mentioned in both [RFC6781] and [RFC7583].
403 6. References
405 6.1. Normative References
407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
408 Requirement Levels", BCP 14, RFC 2119,
409 DOI 10.17487/RFC2119, March 1997,
410 .
412 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
413 Rose, "DNS Security Introduction and Requirements",
414 RFC 4033, DOI 10.17487/RFC4033, March 2005,
415 .
417 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
418 Rose, "Resource Records for the DNS Security Extensions",
419 RFC 4034, DOI 10.17487/RFC4034, March 2005,
420 .
422 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
423 Rose, "Protocol Modifications for the DNS Security
424 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
425 .
427 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
428 Security (DNSSEC) Hashed Authenticated Denial of
429 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
430 .
432 [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
433 Opportunistic DNS-Based Authentication of Named Entities
434 (DANE) Transport Layer Security (TLS)", RFC 7672,
435 DOI 10.17487/RFC7672, October 2015,
436 .
438 [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from
439 the Parent via CDS/CDNSKEY", RFC 8078,
440 DOI 10.17487/RFC8078, March 2017,
441 .
443 [RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security
444 Algorithm (EdDSA) for DNSSEC", RFC 8080,
445 DOI 10.17487/RFC8080, February 2017,
446 .
448 6.2. Informative References
450 [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
451 (RR)", RFC 3658, DOI 10.17487/RFC3658, December 2003,
452 .
454 [RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier
455 Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014,
456 November 2010, .
458 [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital
459 Signature Algorithm (DSA) for DNSSEC", RFC 6605,
460 DOI 10.17487/RFC6605, April 2012,
461 .
463 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
464 Operational Practices, Version 2", RFC 6781,
465 DOI 10.17487/RFC6781, December 2012,
466 .
468 [RFC6944] Rose, S., "Applicability Statement: DNS Security (DNSSEC)
469 DNSKEY Algorithm Implementation Status", RFC 6944,
470 DOI 10.17487/RFC6944, April 2013,
471 .
473 [RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking,
474 "DNSSEC Key Rollover Timing Considerations", RFC 7583,
475 DOI 10.17487/RFC7583, October 2015,
476 .
478 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
479 Agility and Selecting Mandatory-to-Implement Algorithms",
480 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
481 .
483 Appendix A. Acknowledgements
485 The information in this document evolved out of several mailing list
486 discussions and also through engagement with participants in the
487 following sessions or events:
489 o DNSSEC Workshop at ICANN 53 (Buenos Aires)
491 o DNSSEC Workshop at ICANN 55 (Marrakech)
493 o Spring 2016 DNS-OARC meeeting (Buenos Aires)
495 o various IETF 95 working groups (Buenos Aires)
497 o Panel session at RIPE 72 (Copenhagen)
499 o DNSSEC Workshop at ICANN 56 (Helsinki)
501 The authors thank the participants of the various sessions for their
502 feedback.
504 The authors thank Viktor Dukhovni for contributing the text for the
505 section on NSEC3 Iterations.
507 Appendix B. Changes
509 NOTE TO RFC EDITOR - Please remove this "Changes" section prior to
510 publication. Thank you.
512 o Revision -05 corrected typos around two other references that did
513 not appear in -04. It also added the new section on "NSEC3
514 Iterations" contributed by Paul Wouters and Viktor Dukhovni.
516 o Revision -04 corrected the references which did not appear in -03
517 due to an error in the markdown source.
519 o Revision -03 removed the reference to the location of the ISP in
520 the text added in version -02.
522 o Revision -02 added text to the resolver section about an example
523 where resolver software did not correctly follow RFC 4035 and
524 treat packets with unknown algorithms as unsigned. The markdown
525 source of this I-D was also migrated to the markdown syntax
526 favored by the 'mmark' tool.
528 o Revision -01 adds text about authoritative servers needing an
529 update if the algorithm is for NSEC/NSEC3. Also expands
530 acknowledgements.
532 Authors' Addresses
534 Dan York
535 Internet Society
537 Email: york@isoc.org
538 URI: https://www.internetsociety.org/
540 Ondrej Sury
541 CZ.NIC
543 Email: ondrej.sury@nic.cz
545 Paul Wouters
546 Red Hat
548 Email: pwouters@redhat.com
550 Olafur Gudmundsson
551 CloudFlare
553 Email: olafur+ietf@cloudflare.com