draft-ietf-dnsop-algorithm-update-03.txt		draft-ietf-dnsop-algorithm-update-04.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: April 26, 2019 October 23, 2018		Expires: April 26, 2019 October 23, 2018
	Algorithm Implementation Requirements and Usage Guidance for DNSSEC		Algorithm Implementation Requirements and Usage Guidance for DNSSEC
	draft-ietf-dnsop-algorithm-update-03		draft-ietf-dnsop-algorithm-update-04
	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
	skipping to change at page 2, line 24 ¶		skipping to change at page 2, line 24 ¶
	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. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	5. Operational Considerations . . . . . . . . . . . . . . . . . 7		5. Operational Considerations . . . . . . . . . . . . . . . . . 7
	6. Implementation Report . . . . . . . . . . . . . . . . . . . . 7		6. Implementation Report . . . . . . . . . . . . . . . . . . . . 8
	6.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 8		6.1. DNSKEY Algorithms . . . . . . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		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 . . . . . . . . . . . . . . . . . . . . . . . 10		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
	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].
	1.1. Updating Algorithm Implementation Requirements and Usage Guidance		1.1. Updating Algorithm Implementation Requirements and Usage Guidance
	skipping to change at page 5, line 26 ¶		skipping to change at page 5, line 26 ¶
	RSASHA512 is NOT RECOMMENDED for DNSSEC Signing because it has not		RSASHA512 is NOT RECOMMENDED for DNSSEC Signing because it has not
	seen wide deployment, but there are some deployments hence DNSSEC		seen wide deployment, but there are some deployments hence DNSSEC
	Validation MUST implement RSASHA512 to ensure interoperability.		Validation MUST implement RSASHA512 to ensure interoperability.
	There is no significant difference in cryptographics strength between		There is no significant difference in cryptographics strength between
	RSASHA512 and RSASHA256, therefore it is discouraged to use		RSASHA512 and RSASHA256, therefore it is discouraged to use
	RSASHA512, as it will only make deprecation of older algorithms		RSASHA512, as it will only make deprecation of older algorithms
	harder. People that wish to use a cryptographically stronger		harder. People that wish to use a cryptographically stronger
	algorithm should switch to elliptic curve cryptography algorithms.		algorithm should switch to elliptic curve cryptography algorithms.
	ECC-GOST (GOST R 34.11-94) has been superseded by GOST R 34.11-2012		ECC-GOST (GOST R 34.10-2001) has been superseded by GOST R 34.10-2012
	in [RFC6986]. The GOST R 34.11-2012 hasn't been standardized for use		in [RFC7091]. The GOST R 34.10-2012 hasn't been standardized for use
	in DNSSEC.		in DNSSEC.
	ECDSAP256SHA256 provides more cryptographic strength with a shorter		ECDSAP256SHA256 provides more cryptographic strength with a shorter
	signature length than either RSASHA256 or RSASHA512. ECDSAP256SHA256		signature length than either RSASHA256 or RSASHA512. ECDSAP256SHA256
	has been widely deployed and therefore it is now at MUST level for		has been widely deployed and therefore it is now at MUST level for
	both validation and signing. It is RECOMMENDED to use deterministic		both validation and signing. It is RECOMMENDED to use deterministic
	digital signature generation procedure of the ECDSA ([RFC6979]) when		digital signature generation procedure of the ECDSA ([RFC6979]) when
	implementing ECDSAP256SHA256 (and ECDSAP384SHA384).		implementing ECDSAP256SHA256 (and ECDSAP384SHA384).
	ECDSAP384SHA384 shares the same properties as ECDSAP256SHA256, but		ECDSAP384SHA384 shares the same properties as ECDSAP256SHA256, but
	skipping to change at page 6, line 43 ¶		skipping to change at page 6, line 43 ¶
	NULL is a special case, see [RFC8078]		NULL is a special case, see [RFC8078]
	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 validation, but it is NOT RECOMMENDED for use in generating		implement validation, but it is NOT RECOMMENDED for use in generating
	new DS and CDS records. (See Operational Considerations for caveats		new DS and CDS 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 superseded by GOST R 34.11-2012 in
			[RFC6986]. The GOST R 34.11-2012 hasn't been standardized for use in
			DNSSEC.
	SHA-384 shares the same properties as SHA-256, but offers a modest		SHA-384 shares the same properties as SHA-256, but offers a modest
	security advantage over SHA-384 (384-bits of strength versus		security advantage over SHA-384 (384-bits of strength versus
	256-bits). For most applications of DNSSEC, SHA-256 should be		256-bits). For most applications of DNSSEC, SHA-256 should be
	satisfactory and robust for the foreseeable future, and is therefore		satisfactory and robust for the foreseeable future, and is therefore
	recommended for DS and CDS records. While it is unlikely for a		recommended for DS and CDS records. While it is unlikely for a
	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.
	skipping to change at page 10, line 9 ¶		skipping to change at page 10, line 14 ¶
	[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:
			Digital Signature Algorithm", RFC 7091,
			DOI 10.17487/RFC7091, December 2013,
			<https://www.rfc-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-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>.
End of changes. 7 change blocks.
	7 lines changed or deleted		14 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/