< draft-york-dnsop-deploying-dnssec-crypto-algs-00.txt		draft-york-dnsop-deploying-dnssec-crypto-algs-01.txt >
	DNSOP Working Group D. York		DNSOP Working Group D. York
	Internet-Draft Internet Society		Internet-Draft Internet Society
	Intended status: Informational O. Sury		Intended status: Informational O. Sury
	Expires: September 22, 2016 CZ.NIC		Expires: January 9, 2017 CZ.NIC
	P. Wouters		P. Wouters
	Red Hat		Red Hat
	O. Gudmundsson		O. Gudmundsson
	CloudFlare		CloudFlare
	March 21, 2016		July 08, 2016
	Observations on Deploying New DNSSEC Cryptographic Algorithms		Observations on Deploying New DNSSEC Cryptographic Algorithms
	draft-york-dnsop-deploying-dnssec-crypto-algs-00		draft-york-dnsop-deploying-dnssec-crypto-algs-01
	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 September 22, 2016.		This Internet-Draft will expire on January 9, 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 44 ¶		skipping to change at page 2, line 44 ¶
	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
	"chain of trust" connecting back to the root of DNS		"chain of trust" connecting back to the root of DNS
			o Generation of NSEC/NSEC3 responses by authoritative DNS servers
	o Validation of DNSSEC signatures by DNS resolvers		o Validation of DNSSEC signatures by DNS resolvers
	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.
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 29 ¶
	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.
	2.2. Authoritative DNS Servers		2.2. Authoritative DNS Servers
	Authoritative DNS servers serve out signed DNS records. Serving new		Authoritative DNS servers serve out signed DNS records. Serving new
	DNSSEC signing algorithms should not be a problem as a well-written		DNSSEC signing algorithms should not be a problem as a well-written
	authoritative DNS server implementation should be agnostic to the RR		authoritative DNS server implementation should be agnostic to the RR
	DATA they serve. Note that some authoritative server implementations		DATA they serve.
	could include DNSSEC signing as part of the server and thus also fall
	into the "Signing Software" category below.
	[NOTE(OS): Do we also address new NSEC/NSEC3 hashing algorithms?		The one exception is if the new cryptographic algorithms are used in
	Because that would require update in the authoritative DNS server.]		the creation of NSEC/NSEC3 responses. In the case of new NSEC/NSEC3
			algorithms, the authoritative DNS server software would need to be
			updated to be able to use the new algorithms.
			Note that some authoritative server implementations could include
			DNSSEC signing as part of the server and thus also fall into the
			"Signing Software" category below.
	2.3. Signing Software		2.3. Signing Software
	The software performing the signing of the records needs to be		The software performing the signing of the records needs to be
	updated with the new cryptographic algorithm.		updated with the new cryptographic algorithm.
	User interfaces that allow users to interact with the DNSSEC signing		User interfaces that allow users to interact with the DNSSEC signing
	software may also need to be updated to reflect the existence of the		software may also need to be updated to reflect the existence of the
	new algorithm.		new algorithm.
	Note that the key and signatures with the new algorithm will need to		Note that the key and signatures with the new algorithm will need to
	co-exist with the existing key and signatures for some period of		co-exist with the existing key and signatures for some period of
	time, which would have some impact on the size of the DNS records.		time. This will have an impact on the size of the DNS records.
	[NOTE(OS): Shouldn't we just update the language that requires the		[NOTE(OS): Shouldn't we just update the language that requires the
	resolver to be so strict and finally be done with this requirement?		resolver to be so strict and finally be done with this requirement?
	Or just give a recommendation in the paragraph on resolver here?]		Or just give a recommendation in the paragraph on resolver here?]
	[NOTE(DY): I just noticed that "Signing software" or "Signers" does		One issue that has been identified is that not all commonly-used
	not exist in the "DNS Terminology draft at		signing software releases include support for an algorithm rollover.
	https://tools.ietf.org/html/rfc7719 ]		This software would need to be updated to support rolling an
			algorithm before any new algorithms could be deployed.
	2.4. Registries		2.4. Registries
	The registry for a top-level domain (TLD) needs to accept DS records		The registry for a top-level domain (TLD) needs to accept DS records
	using the new cryptographic algorithm.		using the new cryptographic algorithm.
	Observations to date have shown that some registries only accept DS		Observations to date have shown that some registries only accept DS
	records with certain algorithms. Registry representatives have		records with certain algorithms. Registry representatives have
	indicated that they verify the accuracy of DS records to reduce		indicated that they verify the accuracy of DS records to reduce
	technical support incidents and ensure customers do not mistakenly		technical support incidents and ensure customers do not mistakenly
	skipping to change at page 6, line 4 ¶		skipping to change at page 6, line 9 ¶
	An issue is that many registrar web interfaces only allow the input		An issue is that many registrar web interfaces only allow the input
	of DS records using a listed set of DNSSEC algorithms. Any new		of DS records using a listed set of DNSSEC algorithms. Any new
	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-ds]		Note that work is currently underway in [I-D.ietf-dnsop-maintain-ds]
	to provide an automated mechanism to update the DS records with a		to provide an automated mechanism to update the DS records with a
	registry. If this method becomes widely adopted, registrar web		registry. If this method becomes widely adopted, registrar web
	interfaces will 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.
	DNS hosting operators need to update their authoritative DNS server		DNS hosting operators need to update their authoritative DNS server
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 7 ¶
	used by recursive resolver software and signing software.		used by recursive resolver software and signing software.
	3. Conclusion		3. Conclusion
	This document provides a view into the steps necessary for the		This document provides a view into the steps necessary for the
	deployment of new cryptographic algorithms in DNSSEC at the time of		deployment of new cryptographic algorithms in DNSSEC at the time of
	this publication. In order to more rapidly roll out new DNSSEC		this publication. In order to more rapidly roll out new DNSSEC
	algorithms, these steps must be understood and hopefully improved		algorithms, these steps must be understood and hopefully improved
	over time.		over time.
			It should be noted that a common theme to emerge from all discussions
			is a general reluctance to update or change any DNS-related software.
			"If it isn't broken, don't fix it" is a common refrain. While
			perhaps understandable from a stability point of view, this attitude
			creates a challenge for deploying new algorithms.
			One potential idea suggested during discussions was for some kind of
			web-based testing tool that could assist people in understanding what
			algorithms are supported by different servers and sites.
			It is also quite clear that any deployment of new algorithms for
			DNSSEC use will take a few years to propagate throughout the
			infrastructure. This needs to be factored in as new algorithms are
			proposed.
	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] and		changing DNSSEC algorithms that are mentioned in both [RFC6781] and
	[RFC7583].		[RFC7583].
	6. Acknowledgements		6. 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
	DNSSEC Workshop sessions at ICANN 53 (Buenos Aires) and ICANN 55		following sessions or events:
	(Marrakech).
	7. References		o DNSSEC Workshop at ICANN 53 (Buenos Aires)
	7.1. Normative References		o DNSSEC Workshop at ICANN 55 (Marrakech)
			o Spring 2016 DNS-OARC meeeting (Buenos Aires)
			o various IETF 95 working groups (Buenos Aires)
			o Panel session at RIPE 72 (Copenhagen)
			o DNSSEC Workshop at ICANN 56 (Helsinki)
			The authors thank the participants of the various sessions for their
			feedback.
			7. Changes
			NOTE TO RFC EDITOR - Please remove this "Changes" section prior to
			publication. Thank you.
			o Revision -01 adds text about authoritative servers needing an
			update if the algorithm is for NSEC/NSEC3. Also expands
			acknowledgements.
			8. References
			8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	7.2. Informative References		8.2. Informative References
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements", RFC		Rose, "DNS Security Introduction and Requirements", RFC
	4033, DOI 10.17487/RFC4033, March 2005,		4033, DOI 10.17487/RFC4033, March 2005,
	<http://www.rfc-editor.org/info/rfc4033>.		<http://www.rfc-editor.org/info/rfc4033>.
	[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Resource Records for the DNS Security Extensions",		Rose, "Resource Records for the DNS Security Extensions",
	RFC 4034, DOI 10.17487/RFC4034, March 2005,		RFC 4034, DOI 10.17487/RFC4034, March 2005,
	<http://www.rfc-editor.org/info/rfc4034>.		<http://www.rfc-editor.org/info/rfc4034>.
End of changes. 16 change blocks.
	20 lines changed or deleted		63 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/