< draft-york-dnsop-deploying-dnssec-crypto-algs-02.txt		draft-york-dnsop-deploying-dnssec-crypto-algs-03.txt >
	skipping to change at page 1, line 14 ¶		skipping to change at page 1, line 14 ¶
	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 4, 2017 CZ.NIC
	P. Wouters		P. Wouters
	Red Hat		Red Hat
	O. Gudmundsson		O. Gudmundsson
	CloudFlare		CloudFlare
	October 31, 2016		October 31, 2016
	Observations on Deploying New DNSSEC Cryptographic Algorithms		Observations on Deploying New DNSSEC Cryptographic Algorithms
	draft-york-dnsop-deploying-dnssec-crypto-algs-02		draft-york-dnsop-deploying-dnssec-crypto-algs-03
	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 4, line 42 ¶		skipping to change at page 4, line 42 ¶
	"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.
	Note that in at least one 2016 case (an ISP in Sweden) the resolver		Note that in at least one 2016 case the resolver software deployed on
	software deployed on customer premises turned out not to be compliant		customer premises by an Internet service provider (ISP) turned out
	with RFC 4035. Instead of ignoring the signatures using unknown		not to be compliant with RFC 4035. Instead of ignoring the
	algorithms and treating the zones as unsigned, the validating		signatures using unknown algorithms and treating the zones as
	resolver rejected the signatures and returned a SERVFAIL to the DNS		unsigned, the validating resolver rejected the signatures and
	query. This resulted in the ISP turning off DNSSEC validation on the		returned a SERVFAIL to the DNS query. This resulted in the ISP
	equipment. Further investigation showed that a newer version of the		turning off DNSSEC validation on the equipment. Further
	resolver software did correctly support ECDSA, but now all customer		investigation showed that a newer version of the resolver software
	premises equipment must be updated to this new version.		did correctly support ECDSA, but now all customer premises equipment
			must be updated to this new version.
	The point is that it is not safe to assume all resolver software will		The point is that it is not safe to assume all resolver software will
	correctly implement this part of RFC 4035.		correctly implement this part of RFC 4035.
	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.		DATA they serve.
	skipping to change at page 8, line 48 ¶		skipping to change at page 8, line 48 ¶
	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 -03 removed the reference to the location of the ISP in
			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
	update if the algorithm is for NSEC/NSEC3. Also expands		update if the algorithm is for NSEC/NSEC3. Also expands
	acknowledgements.		acknowledgements.
End of changes. 3 change blocks.
	10 lines changed or deleted		14 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/