draft-ietf-dnsop-algorithm-update-00.txt		draft-ietf-dnsop-algorithm-update-01.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: September 22, 2018 March 21, 2018		Expires: December 7, 2018 June 5, 2018
	Algorithm Implementation Requirements and Usage Guidance for DNSSEC		Algorithm Implementation Requirements and Usage Guidance for DNSSEC
	draft-ietf-dnsop-algorithm-update-00		draft-ietf-dnsop-algorithm-update-01
	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 guidance to ensure that there		implementation requirements and usage guidance 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
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 https://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, 2018.		This Internet-Draft will expire on December 7, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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		(https://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. Updating Algorithm Implementation Requirements and Usage		1.1. Updating Algorithm Implementation Requirements and Usage
	Guidance . . . . . . . . . . . . . . . . . . . . . . . . 2		Guidance . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 2		1.2. Updating Algorithm Requirement Levels . . . . . . . . . . 2
	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 . . . . . . . . . . . . . 5		3.2. DNSKEY Algorithm Recommendation . . . . . . . . . . . . . 6
	3.3. DS and CDS Algorithms . . . . . . . . . . . . . . . . . . 6		3.3. DS and CDS Algorithms . . . . . . . . . . . . . . . . . . 6
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 6		4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	5. Operational Considerations . . . . . . . . . . . . . . . . . 7		5. Operational Considerations . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Normative References . . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . 8
	8.2. Informative References . . . . . . . . . . . . . . . . . 8		8.2. Informative References . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	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
	interoperability, a set of "mandatory-to-implement" DNSKEY algorithms		interoperability, a set of "mandatory-to-implement" DNSKEY algorithms
	are defined. This document obsoletes [RFC6944].		are defined. This document obsoletes [RFC6944].
	skipping to change at page 4, line 40 ¶		skipping to change at page 4, line 40 ¶
	+--------+--------------------+-----------------+-------------------+		+--------+--------------------+-----------------+-------------------+
	| 1 | RSAMD5 | MUST NOT | MUST NOT |		| 1 | RSAMD5 | MUST NOT | MUST NOT |
	| 3 | DSA | MUST NOT | MUST NOT |		| 3 | DSA | MUST NOT | MUST NOT |
	| 5 | RSASHA1 | NOT RECOMMENDED | MUST |		| 5 | RSASHA1 | NOT RECOMMENDED | MUST |
	| 6 | DSA-NSEC3-SHA1 | MUST NOT | MUST NOT |		| 6 | DSA-NSEC3-SHA1 | MUST NOT | MUST NOT |
	| 7 | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST |		| 7 | RSASHA1-NSEC3-SHA1 | NOT RECOMMENDED | MUST |
	| 8 | RSASHA256 | MUST | MUST |		| 8 | RSASHA256 | MUST | MUST |
	| 10 | RSASHA512 | NOT RECOMMENDED | MUST |		| 10 | RSASHA512 | NOT RECOMMENDED | MUST |
	| 12 | ECC-GOST | MUST NOT | MAY |		| 12 | ECC-GOST | MUST NOT | MAY |
	| 13 | ECDSAP256SHA256 | MUST | MUST |		| 13 | ECDSAP256SHA256 | MUST | MUST |
	| 14 | ECDSAP384SHA384 | NOT RECOMMENDED | RECOMMENDED |		| 14 | ECDSAP384SHA384 | MAY | RECOMMENDED |
	| 15 | ED25519 | RECOMMENDED | RECOMMENDED |		| 15 | ED25519 | RECOMMENDED | RECOMMENDED |
	| 16 | ED448 | MAY | RECOMMENDED |		| 16 | ED448 | MAY | RECOMMENDED |
	+--------+--------------------+-----------------+-------------------+		+--------+--------------------+-----------------+-------------------+
	RSAMD5 is not widely deployed and there is an industry-wide trend to		RSAMD5 is not widely deployed and there is an industry-wide trend to
	deprecate MD5 usage.		deprecate MD5 usage.
	RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones		RSASHA1 and RSASHA1-NSEC3-SHA1 are widely deployed, although zones
	deploying it are recommended to switch to ECDSAP256SHA256 as there is		deploying it are recommended to switch to ECDSAP256SHA256 as there is
	an industry-wide trend to move to elliptic curve cryptography.		an industry-wide trend to move to elliptic curve cryptography.
	skipping to change at page 5, line 32 ¶		skipping to change at page 5, line 32 ¶
	in DNSSEC.		in DNSSEC.
	ECDSAP256SHA256 provide more strength for signature size than		ECDSAP256SHA256 provide more strength for signature size than
	RSASHA256 and RSASHA512 variants. ECDSAP256SHA256 has been widely		RSASHA256 and RSASHA512 variants. ECDSAP256SHA256 has been widely
	deployed and therefore it is now at MUST level for both validation		deployed and therefore it is now at MUST level for both validation
	and signing. It is RECOMMENDED to use deterministic digital		and signing. It is RECOMMENDED to use deterministic digital
	signature generation procedure of the ECDSA ([RFC6979]) when		signature generation procedure of the ECDSA ([RFC6979]) when
	implementing ECDSAP256SHA256 (and ECDSAP384SHA384).		implementing ECDSAP256SHA256 (and ECDSAP384SHA384).
	ECDSAP384SHA384 share the same properties as ECDSAP256SHA256, but		ECDSAP384SHA384 share the same properties as ECDSAP256SHA256, but
	offers only a little advantage over ECDSAP256SHA256 and has not seen		offers a modest security advantage over ECDSAP256SHA256 (192-bits of
	wide deployment, so the usage of this algorithm is discouraged,		strength versus 128-bits). For most applications of DNSSEC,
	especially for signing.		ECDSAP256SHA256 should be satisfactory and robust for the foreseeable
			future, and is therefore recommended for signing. While it is
			unlikely for a DNSSEC use case which requires 192-bit security
			strength to arise, ECDSA384SHA384 is provided for such applications
			and it MAY be used for signing in these cases.
	ED25519 and ED448 uses Edwards-curve Digital Security Algorithm		ED25519 and ED448 uses Edwards-curve Digital Security Algorithm
	(EdDSA). There are three main advantages of the EdDSA algorithm: It		(EdDSA). There are three main advantages of the EdDSA algorithm: It
	does not require the use of a unique random number for each		does not require the use of a unique random number for each
	signature, there are no padding or truncation issues as with ECDSA,		signature, there are no padding or truncation issues as with ECDSA,
	and it is more resilient to side-channel attacks. Furthermore, EdDSA		and it is more resilient to side-channel attacks. Furthermore, EdDSA
	cryptography is less prone to implementation errors ([RFC8080]). It		cryptography is less prone to implementation errors ([RFC8032],
	is expected that ED25519 will become the future RECOMMENDED default		[RFC8080]). It is expected that ED25519 will become the future
	algorithm once there's enough support for this algorithm in the		RECOMMENDED default algorithm once there's enough support for this
	deployed DNSSEC validators.		algorithm in the deployed DNSSEC validators.
	3.2. DNSKEY Algorithm Recommendation		3.2. DNSKEY Algorithm Recommendation
	Operation recommendation for new and existing deployments.		Operation recommendation for new and existing deployments.
	Due to industry-wide trend to move to elliptic curve cryptography,		Due to industry-wide trend to move to elliptic curve cryptography,
	the ECDSAP256SHA256 is RECOMMENDED to be used by new DNSSEC		the ECDSAP256SHA256 is RECOMMENDED to be used by new DNSSEC
	deployments, and users of RSA based algorithms SHOULD upgrade to		deployments, and users of RSA based algorithms SHOULD upgrade to
	ECDSAP256SHA256.		ECDSAP256SHA256.
	skipping to change at page 6, line 36 ¶		skipping to change at page 6, line 43 ¶
	SHA-1 is still in wide use for DS records, so validators MUST		SHA-1 is still in wide use for DS records, so validators MUST
	implement the validation, but it is disallowed to use SHA-1 to		implement the validation, but it is disallowed to use SHA-1 to
	generate new DS records. (See Operational Considerations for caveats		generate new DS records. (See Operational Considerations for caveats
	when upgrading from SHA-1 to SHA-256 DS Algorithm.)		when upgrading from SHA-1 to SHA-256 DS Algorithm.)
	SHA-256 is in wide use and considered strong.		SHA-256 is in wide use and considered strong.
	GOST R 34.11-94 has been deprecated by [RFC6986].		GOST R 34.11-94 has been deprecated by [RFC6986].
	SHA-384 is not in wide use. It is still recommended to be supported		SHA-384 share the same properties as SHA-256, but offers a modest
	in validators so that adoption can increase.		security advantage over SHA-384 (384-bits of strength versus
			256-bits). For most applications of DNSSEC, SHA-256 should be
			satisfactory and robust for the foreseeable future, and is therefore
			recommended for DS/CDS records. While it is unlikely for a DNSSEC
			use case which requires 384-bit security strength to arise, SHA-384
			is provided for such applications and it MAY be used for generating
			DS/CDS records in these cases.
	4. Security Considerations		4. Security Considerations
	The security of cryptographic-based systems depends on both the		The security of cryptographic-based systems depends on both the
	strength of the cryptographic algorithms chosen and the strength of		strength of the cryptographic algorithms chosen and the strength of
	the keys used with those algorithms. The security also depends on		the keys used with those algorithms. The security also depends on
	the engineering of the protocol used by the system to ensure that		the engineering of the protocol used by the system to ensure that
	there are no non-cryptographic ways to bypass the security of the		there are no non-cryptographic ways to bypass the security of the
	overall system.		overall system.
	skipping to change at page 7, line 37 ¶		skipping to change at page 7, line 51 ¶
	This document makes no requests of IANA.		This document makes no requests of IANA.
	7. Acknowledgements		7. 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.
	We wish to thank Roland van Rijswijk-Deij, Olafur Gudmundsson and		We wish to thank Michael Sinatra, Roland van Rijswijk-Deij, Olafur
	Paul Hoffman for their imminent feedback.		Gudmundsson and Paul Hoffman for their imminent feedback.
	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.
	8. References		8. References
	8.1. Normative 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,		Requirement Levels", BCP 14, RFC 2119,
	skipping to change at page 9, line 15 ¶		skipping to change at page 9, line 24 ¶
	[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-editor.org/info/rfc7344>.		<https://www.rfc-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-editor.org/info/rfc7583>.		<https://www.rfc-editor.org/info/rfc7583>.
			[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
			Signature Algorithm (EdDSA)", RFC 8032,
			DOI 10.17487/RFC8032, January 2017,
			<https://www.rfc-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-editor.org/info/rfc8078>.		<https://www.rfc-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-editor.org/info/rfc8080>.		<https://www.rfc-editor.org/info/rfc8080>.
End of changes. 12 change blocks.
	19 lines changed or deleted		34 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/