draft-ietf-dnsop-algorithm-update-08.txt		draft-ietf-dnsop-algorithm-update-09.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: October 11, 2019 April 9, 2019		Expires: October 12, 2019 April 10, 2019
	Algorithm Implementation Requirements and Usage Guidance for DNSSEC		Algorithm Implementation Requirements and Usage Guidance for DNSSEC
	draft-ietf-dnsop-algorithm-update-08		draft-ietf-dnsop-algorithm-update-09
	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 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 October 11, 2019.		This Internet-Draft will expire on October 12, 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		(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 5, line 15 ¶		skipping to change at page 5, line 15 ¶
	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.
	RSASHA1 does not support NSEC3. RSASHA1-NSEC3-SHA1 can be used with		RSASHA1 does not support NSEC3. RSASHA1-NSEC3-SHA1 can be used with
	or without NSEC3.		or without NSEC3.
	DSA and DSA-NSEC3-SHA1 are not widely deployed and vulnerable to		DSA and DSA-NSEC3-SHA1 are not widely deployed and vulnerable to
	private key compromise when generating signatures using a weak or		private key compromise when generating signatures using a weak or
	compromised random number generator.		compromised random number generator.
	RSASHA256 is in wide use and considered strong.		RSASHA256 is in wide use and considered strong. It has been the
			default algorithm for a number of years and is now slowly being
			replaced with ECDSAP256SHA256 due to its shorter key and signature
			size, resulting in smaller DNS packets.
	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 cryptographic strength between		There is no significant difference in cryptographic 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 who wish to use a cryptographically stronger		harder. People who wish to use a cryptographically stronger
	algorithm should switch to elliptic curve cryptography algorithms.		algorithm should switch to elliptic curve cryptography algorithms.
	skipping to change at page 6, line 9 ¶		skipping to change at page 6, line 12 ¶
	require the use of a unique random number for each signature, there		require the use of a unique random number for each signature, there
	are no padding or truncation issues as with ECDSA, and it is more		are no padding or truncation issues as with ECDSA, and it is more
	resilient to side-channel attacks. Furthermore, EdDSA cryptography		resilient to side-channel attacks. Furthermore, EdDSA cryptography
	is less prone to implementation errors ([RFC8032], [RFC8080]). It is		is less prone to implementation errors ([RFC8032], [RFC8080]). It is
	expected that ED25519 will become the future RECOMMENDED default		expected that ED25519 will become the future RECOMMENDED default
	algorithm once there's enough support for this algorithm in the		algorithm once there's enough support for this algorithm in the
	deployed DNSSEC validators.		deployed DNSSEC validators.
	3.2. DNSKEY Algorithm Recommendation		3.2. DNSKEY Algorithm Recommendation
	Operational recommendation for new and existing deployments.
	Due to the industry-wide trend towards elliptic curve cryptography,		Due to the industry-wide trend towards elliptic curve cryptography,
	ECDSAP256SHA256 is the RECOMMENDED DNSKEY algorithm for use by new		ECDSAP256SHA256 is the RECOMMENDED DNSKEY algorithm for use by new
	DNSSEC deployments, and users of RSA-based algorithms SHOULD upgrade		DNSSEC deployments, and users of RSA-based algorithms SHOULD upgrade
	to ECDSAP256SHA256.		to ECDSAP256SHA256.
	3.3. DS and CDS Algorithms		3.3. DS and CDS Algorithms
	Recommendations for Delegation Signer Digest Algorithms [DNSKEY-IANA]		Recommendations for Delegation Signer Digest Algorithms [DNSKEY-IANA]
	These recommendations also apply to the CDS RRTYPE as specified in		These recommendations also apply to the CDS RRTYPE as specified in
	[RFC7344]		[RFC7344]
	skipping to change at page 7, line 16 ¶		skipping to change at page 7, line 17 ¶
	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: SHA-256 is		Operation recommendation for new and existing deployments: SHA-256 is
	the RECOMMENDED DS and CDS algorithm.		the RECOMMENDED DS and CDS algorithm.
	4. Implementation Status		4. Implementation Status
	[RFC Editor Note: Please remove this entire seciton plus all		[RFC Editor Note: Please remove this entire section plus all
	references to [RFC7942] prior to publication as an RFC.]		references to [RFC7942] prior to publication as an RFC.]
	This section records the status of known implementations of the		This section records the status of known implementations of the
	protocol defined by this specification at the time of posting of this		protocol defined by this specification at the time of posting of this
	Internet-Draft, and is based on a proposal described in [RFC7942].		Internet-Draft, and is based on a proposal described in [RFC7942].
	The description of implementations in this section is intended to		The description of implementations in this section is intended to
	assist the IETF in its decision processes in progressing drafts to		assist the IETF in its decision processes in progressing drafts to
	RFCs. Please note that the listing of any individual implementation		RFCs. Please note that the listing of any individual implementation
	here does not imply endorsement by the IETF. Furthermore, no effort		here does not imply endorsement by the IETF. Furthermore, no effort
	has been spent to verify the information presented here that was		has been spent to verify the information presented here that was
	skipping to change at page 8, line 32 ¶		skipping to change at page 8, line 32 ¶
	5. Security Considerations		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 use in DNSSEC, specifically with the selection of
	"mandatory-to-implement" algorithms. The algorithms identified in		"mandatory-to-implement" algorithms. The algorithms identified in
	this document as MUST or RECOMMENDED to implement are not known to be		this document as MUST or RECOMMENDED to implement are not known to be
	broken (in the cryptographic sense) at the current time, and		broken (in the cryptographic sense) at the current time, and
	cryptographic research so far leads us to believe that they are		cryptographic research so far leads us to believe that they are
	likely to remain secure into the foreseeable future. However, this		likely to remain secure into the foreseeable future. However, this
	isn't necessarily forever, and it is expected that new revisions of		isn't necessarily forever, and it is expected that new revisions of
	this document will be issued from time to time to reflect the current		this document will be issued from time to time to reflect the current
	best practices in this area.		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
End of changes. 8 change blocks.
	9 lines changed or deleted		10 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/