< draft-york-dnsop-deploying-dnssec-crypto-algs-04.txt		draft-york-dnsop-deploying-dnssec-crypto-algs-05.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 18, 2017 CZ.NIC		Expires: January 4, 2018 CZ.NIC
	P. Wouters		P. Wouters
	Red Hat		Red Hat
	O. Gudmundsson		O. Gudmundsson
	CloudFlare		CloudFlare
	November 14, 2016		July 3, 2017
	Observations on Deploying New DNSSEC Cryptographic Algorithms		Observations on Deploying New DNSSEC Cryptographic Algorithms
	draft-york-dnsop-deploying-dnssec-crypto-algs-04		draft-york-dnsop-deploying-dnssec-crypto-algs-05
	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 18, 2017.		This Internet-Draft will expire on January 4, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	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 . . . . . . . . . . . . . . . . . . . . . . . 6		2.3.1. NSEC3 Iterations . . . . . . . . . . . . . . . . . . 5
	2.5. Registrars . . . . . . . . . . . . . . . . . . . . . . . 6		2.4. Registries . . . . . . . . . . . . . . . . . . . . . . . 7
	2.6. DNS Hosting Operators . . . . . . . . . . . . . . . . . . 7		2.5. Registrars . . . . . . . . . . . . . . . . . . . . . . . 7
	2.7. Applications . . . . . . . . . . . . . . . . . . . . . . 7		2.6. DNS Hosting Operators . . . . . . . . . . . . . . . . . . 8
	3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7		2.7. Applications . . . . . . . . . . . . . . . . . . . . . . 8
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6.1. Normative References . . . . . . . . . . . . . . . . . . 8		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6.2. Informative References . . . . . . . . . . . . . . . . . 9		6.1. Normative References . . . . . . . . . . . . . . . . . . 9
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9		6.2. Informative References . . . . . . . . . . . . . . . . . 10
	Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 10		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The DNS Security Extensions (DNSSEC), broadly defined in [RFC4033],		The DNS Security Extensions (DNSSEC), broadly defined in [RFC4033],
	[RFC4034] and [RFC4035], make use of cryptographic algorithms in both		[RFC4034] and [RFC4035], make use of cryptographic algorithms in both
	the signing of DNS records and the validation of DNSSEC signatures by		the signing of DNS records and the 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 which		in [RFC6014]. Note that [RFC6944] provides some guidance as to 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 a new		The ECDSA algorithm [RFC6605] has seen some adoption and the more
	signing algorithm has been proposed: Edwards-curve Digital Signature		recent [RFC8080] specifies the Edwards-curve Digital Signature
	Algorithm (EdDSA) using a choice of two curves, Ed25519 and Ed448,		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
	"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 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.
	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 this		Algorithm Agility" in [RFC7696] to highlight the importance of 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].		[RFC2119].
	2. Aspects of Deploying New Algorithms		2. Aspects of Deploying New Algorithms
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 36 ¶
	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
	authenticated DS RRset, then the resolver will not be able to verify		in an authenticated DS RRset, then the resolver will not be
	the authentication path to the child zone. In this case, the		able to verify the authentication path to the child zone.
	resolver SHOULD treat the child zone as if it were unsigned."		In this case, the 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.
	Note that in at least one 2016 case the resolver software deployed on		Note that in at least one 2016 case the resolver software deployed on
	customer premises by an Internet service provider (ISP) turned out		customer premises by an Internet service provider (ISP) turned out
	not to be compliant with RFC 4035. Instead of ignoring the		not to be compliant with RFC 4035. Instead of ignoring the
	signatures using unknown algorithms and treating the zones as		signatures using unknown algorithms and treating the zones as
	skipping to change at page 5, line 41 ¶		skipping to change at page 5, line 42 ¶
	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. This will have an 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
	resolver to be so strict and finally be done with this requirement?
	Or just give a recommendation in the paragraph on resolver here?]
	One issue that has been identified is that not all commonly-used		One issue that has been identified is that not all commonly-used
	signing software releases include support for an algorithm rollover.		signing software releases include support for an algorithm rollover.
	This software would need to be updated to support rolling an		This software would need to be updated to support rolling an
	algorithm before any new algorithms could be deployed.		algorithm before any new algorithms could be deployed.
			2.3.1. NSEC3 Iterations
			Implementation experience has shown that the [RFC5155] NSEC3
			iteration count limits are poorly understood and are fragile in the
			context of adoption of elliptic curve(EC)-based algorithms.
			A simple design would have constrained the iteration count only by
			the bit width of the iteration count field (perhaps 12 bits for up
			4096 iterations), with all representable values supported by both
			signers and resolvers. Instead, the iteration count limit was made
			dependent on key size. When the original text of Section 10.3 of
			[RFC5155] was written, the only commonly used DNSSEC key algorithms
			were RSA and DSA. These had similar key sizes with comparable
			security, with DSA slower than RSA. A decision was made to specify
			iteration count limits roughly commensurate with the cost of RSA
			operations for a given key size, and to use the same limits for both
			RSA and DSA. The essential features of the specification are:
			The limits, therefore, are based on the size of the smallest
			zone signing key, rounded up to the nearest table value (or
			rounded down if the key is larger than the largest table
			value).
			...
			Therefore the values in the table MUST be used independent of
			the key algorithm.
			While the specified key-size-dependent limits made some sense for
			both RSA and DSA, they map poorly to elliptic-curve-based (EC) DNSSEC
			algorithms, which only use keys shorter than 1024 bits.
			Nevertheless, popular DNS resolvers apply the specified table of
			limits to EC algorithms, and so zones with EC keys need to cap their
			NSEC3 iteration counts at 150.
			This requirement is surprising to some operators migrating from RSA
			to EC keys. They continue to use iteration counts that work for RSA-
			2048, but which exceed the 150 limit for the smaller EC keys. This
			renders denial-of-existence "Insecure" for the zones in question.
			Some signer implementations allow maximums that are higher than the
			specified key-size-dependent limits, resulting again in resolvers
			possibly returning these answers as "Insecure".
			To avoid surprises, such as downgrade attacks against "SMTP Security
			via Opportunistic DANE TLS" [RFC7672], DNSSEC signers should not use
			an iteration count higher than 150: such iteration counts are prone
			to fail when configuration changes introduce new algorithms.
			Similarly, resolvers should not support configurations with iteration
			count limits below 150, as lower limits may lead to insecure denial
			of existence, even for compliant zones.
	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
	create any outages.		create any outages.
	skipping to change at page 7, line 5 ¶		skipping to change at page 8, 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-ds]		Note that [RFC8078] defines an automated mechanism to update the DS
	to provide an automated mechanism to update the DS records with a		records with a registry. If this method becomes widely adopted,
	registry. If this method becomes widely adopted, registrar web		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.
	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 8, line 25 ¶		skipping to change at page 9, line 23 ¶
	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 mentioned in both [RFC6781] and [RFC7583].
	[RFC7583].
	6. References		6. References
	6.1. Normative References		6.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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 49 ¶
	[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>.
	[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Protocol Modifications for the DNS Security		Rose, "Protocol Modifications for the DNS Security
	Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,		Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
	<http://www.rfc-editor.org/info/rfc4035>.		<http://www.rfc-editor.org/info/rfc4035>.
	6.2. Informative References		[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
			Security (DNSSEC) Hashed Authenticated Denial of
			Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
			<http://www.rfc-editor.org/info/rfc5155>.
	[I-D.ietf-curdle-dnskey-eddsa]		[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
	Sury, O. and R. Edmonds, "EdDSA for DNSSEC", draft-ietf-		Opportunistic DNS-Based Authentication of Named Entities
	curdle-dnskey-eddsa-01 (work in progress), October 2016.		(DANE) Transport Layer Security (TLS)", RFC 7672,
			DOI 10.17487/RFC7672, October 2015,
			<http://www.rfc-editor.org/info/rfc7672>.
	[I-D.ietf-dnsop-maintain-ds]		[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from
	Gudmundsson, O. and P. Wouters, "Managing DS records from		the Parent via CDS/CDNSKEY", RFC 8078,
	parent via CDS/CDNSKEY", draft-ietf-dnsop-maintain-ds-04		DOI 10.17487/RFC8078, March 2017,
	(work in progress), October 2016.		<http://www.rfc-editor.org/info/rfc8078>.
			[RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security
			Algorithm (EdDSA) for DNSSEC", RFC 8080,
			DOI 10.17487/RFC8080, February 2017,
			<http://www.rfc-editor.org/info/rfc8080>.
			6.2. Informative References
			[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
			(RR)", RFC 3658, DOI 10.17487/RFC3658, December 2003,
			<http://www.rfc-editor.org/info/rfc3658>.
	[RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier		[RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier
	Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014,		Allocation for DNSSEC", RFC 6014, DOI 10.17487/RFC6014,
	November 2010, <http://www.rfc-editor.org/info/rfc6014>.		November 2010, <http://www.rfc-editor.org/info/rfc6014>.
	[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital		[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital
	Signature Algorithm (DSA) for DNSSEC", RFC 6605,		Signature Algorithm (DSA) for DNSSEC", RFC 6605,
	DOI 10.17487/RFC6605, April 2012,		DOI 10.17487/RFC6605, April 2012,
	<http://www.rfc-editor.org/info/rfc6605>.		<http://www.rfc-editor.org/info/rfc6605>.
	skipping to change at page 9, line 40 ¶		skipping to change at page 11, line 5 ¶
	[RFC6944] Rose, S., "Applicability Statement: DNS Security (DNSSEC)		[RFC6944] Rose, S., "Applicability Statement: DNS Security (DNSSEC)
	DNSKEY Algorithm Implementation Status", RFC 6944,		DNSKEY Algorithm Implementation Status", RFC 6944,
	DOI 10.17487/RFC6944, April 2013,		DOI 10.17487/RFC6944, April 2013,
	<http://www.rfc-editor.org/info/rfc6944>.		<http://www.rfc-editor.org/info/rfc6944>.
	[RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking,		[RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking,
	"DNSSEC Key Rollover Timing Considerations", RFC 7583,		"DNSSEC Key Rollover Timing Considerations", RFC 7583,
	DOI 10.17487/RFC7583, October 2015,		DOI 10.17487/RFC7583, October 2015,
	<http://www.rfc-editor.org/info/rfc7583>.		<http://www.rfc-editor.org/info/rfc7583>.
			[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
			Agility and Selecting Mandatory-to-Implement Algorithms",
			BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
			<http://www.rfc-editor.org/info/rfc7696>.
	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 10, line 4 ¶		skipping to change at page 11, line 23 ¶
	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.
			The authors thank Viktor Dukhovni for contributing the text for the
			section on NSEC3 Iterations.
	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 -05 corrected typos around two other references that did
			not appear in -04. It also added the new section on "NSEC3
			Iterations" contributed by Paul Wouters and Viktor Dukhovni.
	o Revision -04 corrected the references which did not appear in -03		o Revision -04 corrected the references which did not appear in -03
	due to an error in the markdown source.		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
	skipping to change at page 10, line 38 ¶		skipping to change at page 12, line 17 ¶
	o Revision -01 adds text about authoritative servers needing an		o Revision -01 adds text about authoritative servers needing an
	update if the algorithm is for NSEC/NSEC3. Also expands		update if the algorithm is for NSEC/NSEC3. Also expands
	acknowledgements.		acknowledgements.
	Authors' Addresses		Authors' Addresses
	Dan York		Dan York
	Internet Society		Internet Society
	Email: york@isoc.org		Email: york@isoc.org
			URI: https://www.internetsociety.org/
	Ondrej Sury		Ondrej Sury
	CZ.NIC		CZ.NIC
	Email: ondrej.sury@nic.cz		Email: ondrej.sury@nic.cz
	Paul Wouters		Paul Wouters
	Red Hat		Red Hat
	Email: pwouters@redhat.com		Email: pwouters@redhat.com
End of changes. 22 change blocks.
	46 lines changed or deleted		122 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/