draft-ietf-dnsop-algorithm-update-06.txt		draft-ietf-dnsop-algorithm-update-07.txt
	dnsop P. Wouters		dnsop P. Wouters
	Internet-Draft Red Hat		Internet-Draft Red Hat
	Obsoletes: 6944 (if approved) O. Sury		Obsoletes: 6944 (if approved) O. Sury
	Intended status: Standards Track Internet Systems Consortium		Intended status: Standards Track Internet Systems Consortium
	Expires: August 21, 2019 February 17, 2019		Expires: September 13, 2019 March 12, 2019
	Algorithm Implementation Requirements and Usage Guidance for DNSSEC		Algorithm Implementation Requirements and Usage Guidance for DNSSEC
	draft-ietf-dnsop-algorithm-update-06		draft-ietf-dnsop-algorithm-update-07
	Abstract		Abstract
	The DNSSEC protocol makes use of various cryptographic algorithms in		The DNSSEC protocol makes use of various cryptographic algorithms in
	order to provide authentication of DNS data and proof of non-		order to provide authentication of DNS data and proof of non-
	existence. To ensure interoperability between DNS resolvers and DNS		existence. To ensure interoperability between DNS resolvers and DNS
	authoritative servers, it is necessary to specify a set of algorithm		authoritative servers, it is necessary to specify a set of algorithm
	implementation requirements and usage guidelines to ensure that there		implementation requirements and usage guidelines to ensure that there
	is at least one algorithm that all implementations support. This		is at least one algorithm that all implementations support. This
	document defines the current algorithm implementation requirements		document defines the current algorithm implementation requirements
	and usage guidance for DNSSEC. This document obsoletes [RFC6944].		and usage guidance for DNSSEC. This document obsoletes [RFC6944].
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 https://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 August 21, 2019.		This Internet-Draft will expire on September 13, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Updating Algorithm Implementation Requirements and Usage		1.1. Updating Algorithm Implementation Requirements and Usage
	Guidance . . . . . . . . . . . . . . . . . . . . . . . . 2		Guidance . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3		1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 3
	1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4		1.3. Document Audience . . . . . . . . . . . . . . . . . . . . 4
	2. Conventions Used in This Document . . . . . . . . . . . . . . 4		2. Conventions Used in This Document . . . . . . . . . . . . . . 4
	3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 4		3. Algorithm Selection . . . . . . . . . . . . . . . . . . . . . 4
	3.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 4		3.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 4
	3.2. DNSKEY Algorithm Recommendation . . . . . . . . . . . . . 6		3.2. DNSKEY Algorithm Recommendation . . . . . . . . . . . . . 6
	3.3. DS and CDS Algorithms . . . . . . . . . . . . . . . . . . 6		3.3. DS and CDS Algorithms . . . . . . . . . . . . . . . . . . 6
	3.4. DS and CDS Algorithm Recommendation . . . . . . . . . . . 7		3.4. DS and CDS Algorithm Recommendation . . . . . . . . . . . 7
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 7		4. Implementation Status . . . . . . . . . . . . . . . . . . . . 7
	5. Operational Considerations . . . . . . . . . . . . . . . . . 7		4.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 7
	6. Implementation Report . . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	6.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 8		6. Operational Considerations . . . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	9.1. Normative References . . . . . . . . . . . . . . . . . . 9		9.1. Normative References . . . . . . . . . . . . . . . . . . 9
	9.2. Informative References . . . . . . . . . . . . . . . . . 9		9.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	The DNSSEC signing algorithms are defined by various RFCs, including		The DNSSEC signing algorithms are defined by various RFCs, including
	[RFC4034], [RFC5155], [RFC5702], [RFC5933], [RFC6605], [RFC8080].		[RFC4034], [RFC5155], [RFC5702], [RFC5933], [RFC6605], [RFC8080].
	DNSSEC is used to provide authentication of data. To ensure		DNSSEC is used to provide authentication of data. To ensure
	skipping to change at page 7, line 14 ¶		skipping to change at page 7, line 14 ¶
	DNSSEC use case requiring 384-bit security strength to arise, SHA-384		DNSSEC use case requiring 384-bit security strength to arise, SHA-384
	is provided for such applications and it MAY be used for generating		is provided for such applications and it MAY be used for generating
	DS and CDS records in these cases.		DS and CDS records in these cases.
	3.4. DS and CDS Algorithm Recommendation		3.4. DS and CDS Algorithm Recommendation
	Operation recommendation for new and existing deployments.		Operation recommendation for new and existing deployments.
	The SHA-256 is RECOMMENDED DS and CDS algorithm.		The SHA-256 is RECOMMENDED DS and CDS algorithm.
	4. Security Considerations		4. Implementation Status
			[RFC Editor Note: Please remove this entire seciton plus all
			references to [RFC7942] prior to publication as an RFC.]
			This section records the status of known implementations of the
			protocol defined by this specification at the time of posting of this
			Internet-Draft, and is based on a proposal described in [RFC7942].
			The description of implementations in this section is intended to
			assist the IETF in its decision processes in progressing drafts to
			RFCs. Please note that the listing of any individual implementation
			here does not imply endorsement by the IETF. Furthermore, no effort
			has been spent to verify the information presented here that was
			supplied by IETF contributors. This is not intended as, and must not
			be construed to be, a catalog of available implementations or their
			features. Readers are advised to note that other implementations may
			exist.
			According to RFC 7942, "this will allow reviewers and working groups
			to assign due consideration to documents that have the benefit of
			running code, which may serve as evidence of valuable experimentation
			and feedback that have made the implemented protocols more mature.
			It is up to the individual working groups to use this information as
			they see fit".
			4.1. DNSKEY Algorithms
			The following table contains the status of support in the open-source
			DNS signers and validators in the current released versions as of the
			time writing this document. Usually, the support for specific
			algorithm has to be also included in the cryptographic libraries that
			the software use.
			+--------------------+------+--------+---------+----------+---------+
			| Mnemonics | BIND | Knot | OpenDNS | PowerDNS | Unbound |
			| | | DNS | | | |
			+--------------------+------+--------+---------+----------+---------+
			| RSAMD5 | Y | N | Y | N | N |
			| DSA | Y | N | Y | N | Y |
			| RSASHA1 | Y | Y | Y | Y | Y |
			| DSA-NSEC3-SHA1 | Y | N | Y | N | Y |
			| RSASHA1-NSEC3-SHA1 | Y | Y | Y | Y | Y |
			| RSASHA256 | Y | Y | Y | Y | Y |
			| RSASHA512 | Y | Y | Y | Y | Y |
			| ECC-GOST | N | N | Y | N | Y |
			| ECDSAP256SHA256 | Y | Y | Y | Y | Y |
			| ECDSAP384SHA384 | Y | Y | Y | Y | Y |
			| ED25519 | Y | Y | N | Y | Y |
			| ED448 | N | N | N | Y | Y |
			+--------------------+------+--------+---------+----------+---------+
			5. Security Considerations
	The security of cryptographic systems depends on both the strength of		The security of cryptographic systems depends on both the strength of
	the cryptographic algorithms chosen and the strength of the keys used		the cryptographic algorithms chosen and the strength of the keys used
	with those algorithms. The security also depends on the engineering		with those algorithms. The security also depends on the engineering
	of the protocol used by the system to ensure that there are no non-		of the protocol used by the system to ensure that there are no non-
	cryptographic ways to bypass the security of the overall system.		cryptographic ways to bypass the security of the overall system.
	This document concerns itself with the selection of cryptographic		This document concerns itself with the selection of cryptographic
	algorithms for the use of DNSSEC, specifically with the selection of		algorithms for the use of DNSSEC, specifically with the selection of
	"mandatory-to-implement" algorithms. The algorithms identified in		"mandatory-to-implement" algorithms. The algorithms identified in
	skipping to change at page 7, line 37 ¶		skipping to change at page 8, line 46 ¶
	us to believe that they are likely to remain secure into the		us to believe that they are likely to remain secure into the
	foreseeable future. However, this isn't necessarily forever, and it		foreseeable future. However, this isn't necessarily forever, and it
	is expected that new revisions of this document will be issued from		is expected that new revisions of this document will be issued from
	time to time to reflect the current best practices in this area.		time to time to reflect the current best practices in this area.
	Retiring an algorithm too soon would result in a zone signed with the		Retiring an algorithm too soon would result in a zone signed with the
	retired algorithm being downgraded to the equivalent of an unsigned		retired algorithm being downgraded to the equivalent of an unsigned
	zone. Therefore, algorithm deprecation must be done very slowly and		zone. Therefore, algorithm deprecation must be done very slowly and
	only after careful consideration and measurement of its use.		only after careful consideration and measurement of its use.
	5. Operational Considerations		6. Operational Considerations
	DNSKEY algorithm rollover in a live zone is a complex process. See		DNSKEY algorithm rollover in a live zone is a complex process. See
	[RFC6781] and [RFC7583] for guidelines on how to perform algorithm		[RFC6781] and [RFC7583] for guidelines on how to perform algorithm
	rollovers.		rollovers.
	DS algorithm rollover in a live zone is also a complex process.		DS algorithm rollover in a live zone is also a complex process.
	Upgrading algorithm at the same time as rolling the new KSK key will		Upgrading algorithm at the same time as rolling the new KSK key will
	lead to DNSSEC validation failures, and users MUST upgrade the DS		lead to DNSSEC validation failures, and users MUST upgrade the DS
	algorithm first before rolling the Key Signing Key.		algorithm first before rolling the Key Signing Key.
	6. Implementation Report
	6.1. DNSKEY Algorithms
	The following table contains the status of support in the open-source
	DNS signers and validators in the current released versions as of the
	time writing this document. Usually, the support for specific
	algorithm has to be also included in the cryptographic libraries that
	the software use.
	+--------------------+------+--------+---------+----------+---------+
	| Mnemonics | BIND | Knot | OpenDNS | PowerDNS | Unbound |
	| | | DNS | | | |
	+--------------------+------+--------+---------+----------+---------+
	| RSAMD5 | Y | N | Y | N | N |
	| DSA | Y | N | Y | N | Y |
	| RSASHA1 | Y | Y | Y | Y | Y |
	| DSA-NSEC3-SHA1 | Y | N | Y | N | Y |
	| RSASHA1-NSEC3-SHA1 | Y | Y | Y | Y | Y |
	| RSASHA256 | Y | Y | Y | Y | Y |
	| RSASHA512 | Y | Y | Y | Y | Y |
	| ECC-GOST | N | N | Y | Y | Y |
	| ECDSAP256SHA256 | Y | Y | Y | Y | Y |
	| ECDSAP384SHA384 | Y | Y | Y | Y | Y |
	| ED25519 | Y | Y | N | Y | Y |
	| ED448 | N | N | N | Y | Y |
	+--------------------+------+--------+---------+----------+---------+
	7. IANA Considerations		7. IANA Considerations
	This document makes no requests of IANA.		This document makes no requests of IANA.
	8. Acknowledgements		8. Acknowledgements
	This document borrows text from RFC 4307 by Jeffrey I. Schiller of		This document borrows text from RFC 4307 by Jeffrey I. Schiller of
	the Massachusetts Institute of Technology (MIT) and the 4307bis		the Massachusetts Institute of Technology (MIT) and the 4307bis
	document by Yoav Nir, Tero Kivinen, Paul Wouters and Daniel Migault.		document by Yoav Nir, Tero Kivinen, Paul Wouters and Daniel Migault.
	Much of the original text has been copied verbatim.		Much of the original text has been copied verbatim.
	skipping to change at page 9, line 11 ¶		skipping to change at page 9, line 33 ¶
	Kudos to Roy Arends for bringing the DS rollover issue to the		Kudos to Roy Arends for bringing the DS rollover issue to the
	daylight.		daylight.
	9. References		9. References
	9.1. Normative References		9.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, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	9.2. Informative References		9.2. Informative References
	[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,
	<https://www.rfc-editor.org/info/rfc4034>.		<https://www.rfc-editor.org/info/rfc4034>.
	[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS		[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
	Security (DNSSEC) Hashed Authenticated Denial of		Security (DNSSEC) Hashed Authenticated Denial of
	Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,		Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
	<https://www.rfc-editor.org/info/rfc5155>.		<https://www.rfc-editor.org/info/rfc5155>.
	[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY		[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY
	and RRSIG Resource Records for DNSSEC", RFC 5702,		and RRSIG Resource Records for DNSSEC", RFC 5702,
	DOI 10.17487/RFC5702, October 2009,		DOI 10.17487/RFC5702, October 2009, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc5702>.		editor.org/info/rfc5702>.
	[RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of		[RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of
	GOST Signature Algorithms in DNSKEY and RRSIG Resource		GOST Signature Algorithms in DNSKEY and RRSIG Resource
	Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July		Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July
	2010, <https://www.rfc-editor.org/info/rfc5933>.		2010, <https://www.rfc-editor.org/info/rfc5933>.
	[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, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc6605>.		editor.org/info/rfc6605>.
	[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC		[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
	Operational Practices, Version 2", RFC 6781,		Operational Practices, Version 2", RFC 6781,
	DOI 10.17487/RFC6781, December 2012,		DOI 10.17487/RFC6781, December 2012, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc6781>.		editor.org/info/rfc6781>.
	[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, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc6944>.		editor.org/info/rfc6944>.
	[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature		[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
	Algorithm (DSA) and Elliptic Curve Digital Signature		Algorithm (DSA) and Elliptic Curve Digital Signature
	Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August		Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
	2013, <https://www.rfc-editor.org/info/rfc6979>.		2013, <https://www.rfc-editor.org/info/rfc6979>.
	[RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012:		[RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012:
	Hash Function", RFC 6986, DOI 10.17487/RFC6986, August		Hash Function", RFC 6986, DOI 10.17487/RFC6986, August
	2013, <https://www.rfc-editor.org/info/rfc6986>.		2013, <https://www.rfc-editor.org/info/rfc6986>.
	[RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012:		[RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012:
	Digital Signature Algorithm", RFC 7091,		Digital Signature Algorithm", RFC 7091,
	DOI 10.17487/RFC7091, December 2013,		DOI 10.17487/RFC7091, December 2013, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc7091>.		editor.org/info/rfc7091>.
	[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating		[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
	DNSSEC Delegation Trust Maintenance", RFC 7344,		DNSSEC Delegation Trust Maintenance", RFC 7344,
	DOI 10.17487/RFC7344, September 2014,		DOI 10.17487/RFC7344, September 2014, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc7344>.		editor.org/info/rfc7344>.
	[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, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc7583>.		editor.org/info/rfc7583>.
			[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
			Code: The Implementation Status Section", BCP 205,
			RFC 7942, DOI 10.17487/RFC7942, July 2016,
			<https://www.rfc-editor.org/info/rfc7942>.
	[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital		[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
	Signature Algorithm (EdDSA)", RFC 8032,		Signature Algorithm (EdDSA)", RFC 8032,
	DOI 10.17487/RFC8032, January 2017,		DOI 10.17487/RFC8032, January 2017, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc8032>.		editor.org/info/rfc8032>.
	[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from		[RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from
	the Parent via CDS/CDNSKEY", RFC 8078,		the Parent via CDS/CDNSKEY", RFC 8078,
	DOI 10.17487/RFC8078, March 2017,		DOI 10.17487/RFC8078, March 2017, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc8078>.		editor.org/info/rfc8078>.
	[RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security		[RFC8080] Sury, O. and R. Edmonds, "Edwards-Curve Digital Security
	Algorithm (EdDSA) for DNSSEC", RFC 8080,		Algorithm (EdDSA) for DNSSEC", RFC 8080,
	DOI 10.17487/RFC8080, February 2017,		DOI 10.17487/RFC8080, February 2017, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc8080>.		editor.org/info/rfc8080>.
	[DNSKEY-IANA]		[DNSKEY-IANA]
	"DNSKEY Algorithms", <http://www.iana.org/assignments/		"DNSKEY Algorithms", <http://www.iana.org/assignments/
	dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml>.		dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml>.
	[DS-IANA] "Delegation Signer Digest Algorithms",		[DS-IANA] "Delegation Signer Digest Algorithms",
	<http://www.iana.org/assignments/ds-rr-types/		<http://www.iana.org/assignments/ds-rr-types/
	ds-rr-types.xhtml>.		ds-rr-types.xhtml>.
	Authors' Addresses		Authors' Addresses
End of changes. 20 change blocks.
	63 lines changed or deleted		91 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/