< draft-york-dnsop-deploying-dnssec-crypto-algs-03.txt   draft-york-dnsop-deploying-dnssec-crypto-algs-04.txt >
DNSOP D. York DNSOP D. York
Internet-Draft Internet Society Internet-Draft Internet Society
Intended status: Informational O. Sury Intended status: Informational O. Sury
Expires: May 4, 2017 CZ.NIC Expires: May 18, 2017 CZ.NIC
P. Wouters P. Wouters
Red Hat Red Hat
O. Gudmundsson O. Gudmundsson
CloudFlare CloudFlare
October 31, 2016 November 14, 2016
Observations on Deploying New DNSSEC Cryptographic Algorithms Observations on Deploying New DNSSEC Cryptographic Algorithms
draft-york-dnsop-deploying-dnssec-crypto-algs-03 draft-york-dnsop-deploying-dnssec-crypto-algs-04
Abstract Abstract
As new cryptographic algorithms are developed for use in DNSSEC As new cryptographic algorithms are developed for use in DNSSEC
signing and validation, this document captures the steps needed for signing and validation, this document captures the steps needed for
new algorithms to be deployed and enter general usage. The intent is new algorithms to be deployed and enter general usage. The intent is
to ensure a common understanding of the typical deployment process to ensure a common understanding of the typical deployment process
and potentially identify opportunities for improvement of operations. and potentially identify opportunities for improvement of operations.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2017. This Internet-Draft will expire on May 18, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Aspects of Deploying New Algorithms . . . . . . . . . . . . . 3 2. Aspects of Deploying New Algorithms . . . . . . . . . . . . . 3
2.1. DNS Resolvers Performing Validation . . . . . . . . . . . 4 2.1. DNS Resolvers Performing Validation . . . . . . . . . . . 4
2.1.1. Resolvers and Unknown Algorithms . . . . . . . . . . 4 2.1.1. Resolvers and Unknown Algorithms . . . . . . . . . . 4
2.2. Authoritative DNS Servers . . . . . . . . . . . . . . . . 5 2.2. Authoritative DNS Servers . . . . . . . . . . . . . . . . 5
2.3. Signing Software . . . . . . . . . . . . . . . . . . . . 5 2.3. Signing Software . . . . . . . . . . . . . . . . . . . . 5
2.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 6
2.5. Registrars . . . . . . . . . . . . . . . . . . . . . . . 6 2.5. Registrars . . . . . . . . . . . . . . . . . . . . . . . 6
2.6. DNS Hosting Operators . . . . . . . . . . . . . . . . . . 7 2.6. DNS Hosting Operators . . . . . . . . . . . . . . . . . . 7
2.7. Applications . . . . . . . . . . . . . . . . . . . . . . 7 2.7. Applications . . . . . . . . . . . . . . . . . . . . . . 7
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The DNS Security Extensions (DNSSEC), broadly defined in The DNS Security Extensions (DNSSEC), broadly defined in [RFC4033],
{{?RFC4033}}, {{?RFC4034}} and {{?RFC4035}}, make use of [RFC4034] and [RFC4035], make use of cryptographic algorithms in both
cryptographic algorithms in both the signing of DNS records and the the signing of DNS records and the validation of DNSSEC signatures by
validation of DNSSEC signatures by recursive resolvers. recursive resolvers.
The current list of cryptographic algorithms can be found in the IANA The current list of cryptographic algorithms can be found in the IANA
"Domain Name System Security (DNSSEC) Algorithm Numbers" registry "Domain Name System Security (DNSSEC) Algorithm Numbers" registry
located at <http://www.iana.org/assignments/dns-sec-alg-numbers/> located at <http://www.iana.org/assignments/dns-sec-alg-numbers/>
Algorithms are added to this IANA registry through a process defined Algorithms are added to this IANA registry through a process defined
in {{?RFC6014}}. Note that {{?RFC6944}} provides some guidance as to in [RFC6014]. Note that [RFC6944] provides some guidance as to which
which of these algorithms should be implemented and supported. of these algorithms should be implemented and supported.
Historically DNSSEC signatures have primarily used cryptographic Historically DNSSEC signatures have primarily used cryptographic
algorithms based on RSA keys. As deployment of DNSSEC has increased algorithms based on RSA keys. As deployment of DNSSEC has increased
there has been interest in using newer and more secure algorithms, there has been interest in using newer and more secure algorithms,
particularly those using elliptic curve cryptography. particularly those using elliptic curve cryptography.
The ECDSA algorithm {{?RFC6605}} has seen some adoption and two new
algorithms are being proposed: Ed25519 and Ed448 . The ECDSA algorithm [RFC6605] has seen some adoption and a new
signing algorithm has been proposed: Edwards-curve Digital Signature
Algorithm (EdDSA) using a choice of two curves, Ed25519 and Ed448,
[I-D.ietf-curdle-dnskey-eddsa].
The challenge is that the deployment of a new cryptographic algorithm The challenge is that the deployment of a new cryptographic algorithm
for DNSSEC is not a simple process. DNSSEC algorithms are used for DNSSEC is not a simple process. DNSSEC algorithms are used
throughout the DNS infrastructure for tasks such as: throughout the DNS infrastructure for tasks such as:
o Generation of keys ("DNSKEY" record) for signing o Generation of keys ("DNSKEY" record) for signing
o Creation of DNSSEC signatures in zone files ("RRSIG") o Creation of DNSSEC signatures in zone files ("RRSIG")
o Usage in a Delegation Signer ("DS") record {{?RFC3658}} for the o Usage in a Delegation Signer ("DS") record {{?RFC3658}} for the
skipping to change at page 3, line 30 skipping to change at page 3, line 35
In order for a new cryptographic algorithm to be fully deployed, all In order for a new cryptographic algorithm to be fully deployed, all
aspects of the DNS infrastructure that interact with DNSSEC must be aspects of the DNS infrastructure that interact with DNSSEC must be
updated to use the new algorithm. updated to use the new algorithm.
This document outlines the current understanding of the components of This document outlines the current understanding of the components of
the DNS infrastructure that need to be updated to deploy a new the DNS infrastructure that need to be updated to deploy a new
cryptographic algorithm. cryptographic algorithm.
It should be noted that DNSSEC is not alone in complexity of It should be noted that DNSSEC is not alone in complexity of
deployment. The IAB documented "Guidelines for Cryptographic deployment. The IAB documented "Guidelines for Cryptographic
Algorithm Agility" in {{?RFC7696}} to highlight the importance of Algorithm Agility" in [?!RFC7696] to highlight the importance of this
this issue. issue.
1.1. Terminology 1.1. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
. [RFC2119].
2. Aspects of Deploying New Algorithms 2. Aspects of Deploying New Algorithms
For a new cryptographic algorithm to be deployed in DNSSEC, the For a new cryptographic algorithm to be deployed in DNSSEC, the
following aspects of the DNS infrastructure must be updated: following aspects of the DNS infrastructure must be updated:
o DNS resolvers performing validation o DNS resolvers performing validation
o Authoritative DNS servers o Authoritative DNS servers
o Signing software o Signing software
o Registries o Registries
o Registrars o Registrars
o DNS Hosting Operators o DNS Hosting Operators
o Applications o Applications
Each of these aspects is discussed in more detail below. Each of these aspects is discussed in more detail below.
2.1. DNS Resolvers Performing Validation 2.1. DNS Resolvers Performing Validation
skipping to change at page 4, line 30 skipping to change at page 4, line 34
updated. In some cases this could require waiting until an updated. In some cases this could require waiting until an
underlying library is updated to support the new algorithm. underlying library is updated to support the new algorithm.
Once the software is updated, the updates need to be deployed to all Once the software is updated, the updates need to be deployed to all
resolvers using that software. This can be challenging in cases of resolvers using that software. This can be challenging in cases of
customer-premises equipment (CPE) that does not have any mechanism customer-premises equipment (CPE) that does not have any mechanism
for automatic updating. for automatic updating.
2.1.1. Resolvers and Unknown Algorithms 2.1.1. Resolvers and Unknown Algorithms
It should be noted that section 5.2 of {{?RFC4035}} states: It should be noted that section 5.2 of [RFC4035] states:
"If the resolver does not support any of the algorithms listed in an "If the resolver does not support any of the algorithms listed in an
authenticated DS RRset, then the resolver will not be able to verify authenticated DS RRset, then the resolver will not be able to verify
the authentication path to the child zone. In this case, the the authentication path to the child zone. In this case, the
resolver SHOULD treat the child zone as if it were unsigned." resolver SHOULD treat the child zone as if it were unsigned."
This means that signing a zone with a new algorithm that is not This means that signing a zone with a new algorithm that is not
widely supported by DNS resolvers would result in the signatures widely supported by DNS resolvers would result in the signatures
being ignored and the zone treated as unsigned until resolvers were being ignored and the zone treated as unsigned until resolvers were
updated to recognize the new algorithm. updated to recognize the new algorithm.
skipping to change at page 6, line 44 skipping to change at page 7, line 5
cryptographic algorithms need to be added to the web interface in cryptographic algorithms need to be added to the web interface in
order to be accepted into the registrar's system. order to be accepted into the registrar's system.
Additionally, in a manner similar to registries, many registrars Additionally, in a manner similar to registries, many registrars
perform some level of verification on the DS record to ensure it was perform some level of verification on the DS record to ensure it was
entered "correctly". To do this verification, the registrar's entered "correctly". To do this verification, the registrar's
software needs to understand the algorithm used in the DS record. software needs to understand the algorithm used in the DS record.
This requires the software to be updated to support the new This requires the software to be updated to support the new
algorithm. algorithm.
Note that work is currently underway in {{?I-D.ietf-dnsop-maintain- Note that work is currently underway in [I-D.ietf-dnsop-maintain-ds]
ds}} to provide an automated mechanism to update the DS records with to provide an automated mechanism to update the DS records with a
a registry. If this method becomes widely adopted, registrar web registry. If this method becomes widely adopted, registrar web
interfaces may no longer be needed. interfaces may no longer be needed.
2.6. DNS Hosting Operators 2.6. DNS Hosting Operators
DNS hosting operators are entities that are operating the DNS hosting operators are entities that are operating the
authoritative DNS servers for domains and with DNSSEC are also authoritative DNS servers for domains and with DNSSEC are also
providing the signing of zones. In many cases they may also be the providing the signing of zones. In many cases they may also be the
registrar for domain names, but in other cases they are a separate registrar for domain names, but in other cases they are a separate
entity providing DNS services to customers. entity providing DNS services to customers.
skipping to change at page 8, line 19 skipping to change at page 8, line 25
4. IANA Considerations 4. IANA Considerations
This document does not make any requests of IANA. This document does not make any requests of IANA.
5. Security Considerations 5. Security Considerations
No new security considerations are created by this document. No new security considerations are created by this document.
It should be noted that there are security considerations regarding It should be noted that there are security considerations regarding
changing DNSSEC algorithms that are mentioned in both {{?RFC6781}} changing DNSSEC algorithms that are mentioned in both [RFC6781] and
and {{?RFC7583}}. [RFC7583].
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>.
6.2. Informative References
[I-D.ietf-curdle-dnskey-eddsa]
Sury, O. and R. Edmonds, "EdDSA for DNSSEC", draft-ietf-
curdle-dnskey-eddsa-01 (work in progress), October 2016.
[I-D.ietf-dnsop-maintain-ds]
Gudmundsson, O. and P. Wouters, "Managing DS records from
parent via CDS/CDNSKEY", draft-ietf-dnsop-maintain-ds-04
(work in progress), October 2016.
[RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier
Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014,
November 2010, <http://www.rfc-editor.org/info/rfc6014>.
[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital
Signature Algorithm (DSA) for DNSSEC", RFC 6605,
DOI 10.17487/RFC6605, April 2012,
<http://www.rfc-editor.org/info/rfc6605>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781,
DOI 10.17487/RFC6781, December 2012,
<http://www.rfc-editor.org/info/rfc6781>.
[RFC6944] Rose, S., "Applicability Statement: DNS Security (DNSSEC)
DNSKEY Algorithm Implementation Status", RFC 6944,
DOI 10.17487/RFC6944, April 2013,
<http://www.rfc-editor.org/info/rfc6944>.
[RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking,
"DNSSEC Key Rollover Timing Considerations", RFC 7583,
DOI 10.17487/RFC7583, October 2015,
<http://www.rfc-editor.org/info/rfc7583>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The information in this document evolved out of several mailing list The information in this document evolved out of several mailing list
discussions and also through engagement with participants in the discussions and also through engagement with participants in the
following sessions or events: following sessions or events:
o DNSSEC Workshop at ICANN 53 (Buenos Aires) o DNSSEC Workshop at ICANN 53 (Buenos Aires)
o DNSSEC Workshop at ICANN 55 (Marrakech) o DNSSEC Workshop at ICANN 55 (Marrakech)
skipping to change at page 8, line 35 skipping to change at page 10, line 4
discussions and also through engagement with participants in the discussions and also through engagement with participants in the
following sessions or events: following sessions or events:
o DNSSEC Workshop at ICANN 53 (Buenos Aires) o DNSSEC Workshop at ICANN 53 (Buenos Aires)
o DNSSEC Workshop at ICANN 55 (Marrakech) o DNSSEC Workshop at ICANN 55 (Marrakech)
o Spring 2016 DNS-OARC meeeting (Buenos Aires) o Spring 2016 DNS-OARC meeeting (Buenos Aires)
o various IETF 95 working groups (Buenos Aires) o various IETF 95 working groups (Buenos Aires)
o Panel session at RIPE 72 (Copenhagen) o Panel session at RIPE 72 (Copenhagen)
o DNSSEC Workshop at ICANN 56 (Helsinki) o DNSSEC Workshop at ICANN 56 (Helsinki)
The authors thank the participants of the various sessions for their The authors thank the participants of the various sessions for their
feedback. feedback.
Appendix B. Changes Appendix B. Changes
NOTE TO RFC EDITOR - Please remove this "Changes" section prior to NOTE TO RFC EDITOR - Please remove this "Changes" section prior to
publication. Thank you. publication. Thank you.
o Revision -04 corrected the references which did not appear in -03
due to an error in the markdown source.
o Revision -03 removed the reference to the location of the ISP in o Revision -03 removed the reference to the location of the ISP in
the text added in version -02. the text added in version -02.
o Revision -02 added text to the resolver section about an example o Revision -02 added text to the resolver section about an example
where resolver software did not correctly follow RFC 4035 and where resolver software did not correctly follow RFC 4035 and
treat packets with unknown algorithms as unsigned. The markdown treat packets with unknown algorithms as unsigned. The markdown
source of this I-D was also migrated to the markdown syntax source of this I-D was also migrated to the markdown syntax
favored by the 'mmark' tool. favored by the 'mmark' tool.
o Revision -01 adds text about authoritative servers needing an o Revision -01 adds text about authoritative servers needing an
 End of changes. 18 change blocks. 
27 lines changed or deleted 94 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/