< draft-wouters-sury-dnsop-algorithm-update-00.txt		draft-wouters-sury-dnsop-algorithm-update-01.txt >
	dnsop P. Wouters		dnsop P. Wouters
	Internet-Draft Red Hat		Internet-Draft Red Hat
	Intended status: Standards Track O. Sury		Obsoletes: 6944 (if approved) O. Sury
	Expires: September 18, 2016 CZ.NIC		Intended status: Standards Track CZ.NIC
	March 17, 2016		Expires: September 22, 2016 March 21, 2016
	Algorithm Implementation Requirements and Usage Guidance for DNSSEC		Algorithm Implementation Requirements and Usage Guidance for DNSSEC
	draft-wouters-sury-dnsop-algorithm-update-00		draft-wouters-sury-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
	and usage guidance for DNSSEC.		and usage guidance for DNSSEC. This document obsoletes RFC-6944.
	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 http://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 September 18, 2016.		This Internet-Draft will expire on September 22, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	(http://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
	skipping to change at page 2, line 35 ¶		skipping to change at page 2, line 35 ¶
	8.1. Normative References . . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . 7
	8.2. Informative References . . . . . . . . . . . . . . . . . 7		8.2. Informative References . . . . . . . . . . . . . . . . . 7
	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],		[RFC4034], [RFC5155], [RFC5702], [RFC5933], [RFC6605],
	[I-D.ietf-curdle-dnskey-ed25519] and [I-D.ietf-curdle-dnskey-ed448].		[I-D.ietf-curdle-dnskey-ed25519] and [I-D.ietf-curdle-dnskey-ed448].
	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.		are defined. This document obsoletes [RFC6944].
	1.1. Updating Algorithm Implementation Requirements and Usage Guidance		1.1. Updating Algorithm Implementation Requirements and Usage Guidance
	The field of cryptography evolves continuously. New stronger		The field of cryptography evolves continuously. New stronger
	algorithms appear and existing algorithms are found to be less secure		algorithms appear and existing algorithms are found to be less secure
	then originally thought. Therefore, algorithm implementation		then originally thought. Therefore, algorithm implementation
	requirements and usage guidance need to be updated from time to time		requirements and usage guidance need to be updated from time to time
	to reflect the new reality. The choices for algorithms must be		to reflect the new reality. The choices for algorithms must be
	conservative to minimize the risk of algorithm compromise.		conservative to minimize the risk of algorithm compromise.
	skipping to change at page 4, line 51 ¶		skipping to change at page 4, line 51 ¶
	+--------+--------------------+----------------+-------------------+		+--------+--------------------+----------------+-------------------+
	| Number | Mnemonics | DNSSEC Signing | DNSSEC Validation |		| Number | Mnemonics | DNSSEC Signing | DNSSEC Validation |
	+--------+--------------------+----------------+-------------------+		+--------+--------------------+----------------+-------------------+
	| 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 | MUST- | MUST- |		| 5 | RSASHA1 | MUST- | MUST- |
	| 6 | DSA-NSEC3-SHA1 | MUST NOT | MUST NOT |		| 6 | DSA-NSEC3-SHA1 | MUST NOT | MUST NOT |
	| 7 | RSASHA1-NSEC3-SHA1 | MUST- | MUST- |		| 7 | RSASHA1-NSEC3-SHA1 | MUST- | MUST- |
	| 8 | RSASHA256 | MUST | MUST |		| 8 | RSASHA256 | MUST | MUST |
	| 10 | RSASHA512 | SHOULD | MUST |		| 10 | RSASHA512 | SHOULD- | MUST |
	| 12 | ECC-GOST | SHOULD | SHOULD |		| 12 | ECC-GOST | SHOULD NOT | SHOULD |
	| 13 | ECDSAP256SHA256 | SHOULD+ | MUST |		| 13 | ECDSAP256SHA256 | SHOULD+ | MUST |
	| 14 | ECDSAP384SHA384 | SHOULD+ | SHOULD+ |		| 14 | ECDSAP384SHA384 | SHOULD NOT | SHOULD |
	| TBD | ED25519 | SHOULD+ | SHOULD+ |		| TBD | ED25519 | SHOULD+ | SHOULD+ |
	| TBD | ED448 | SHOULD | SHOULD+ |		| TBD | ED448 | SHOULD | SHOULD+ |
	+--------+--------------------+----------------+-------------------+		+--------+--------------------+----------------+-------------------+
	Table 2		Table 2
	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
	skipping to change at page 5, line 29 ¶		skipping to change at page 5, line 29 ¶
	support NSEC3. RSASHA1-NSEC3-SHA1 can be used with or without NSEC3.		support NSEC3. RSASHA1-NSEC3-SHA1 can be used with 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.
	RSASHA512 is at the SHOULD level for DNSSEC Signing because it has		RSASHA512 is at the SHOULD level for DNSSEC Signing because it has
	not seen wide deployment, but there are some deployments hence DNSSEC		not seen wide deployment, but there are some deployments hence DNSSEC
	Validation MUST implement RSASHA512 to ensure interoperability.		Validation MUST implement RSASHA512 to ensure interoperability.
	ECC-GOST is at the SHOULD level because it has not seen wide		ECC-GOST is at the SHOULD NOT level because it has not seen wide
	deployment.		deployment and the algorithm has not seen wide scrutiny in the crypto
			community.
	ECDSAP256SHA256 and ECDSAP384SHA384 provide more strength for		ECDSAP256SHA256 and ECDSAP384SHA384 provide more strength for
	signature size than RSASHA256 and RSASHA512 variants. It is expected		signature size than RSASHA256 and RSASHA512 variants. It is expected
	to be raised to MUST once they have been deployed more widely for		ECDSAP256SHA256 will be raised to MUST once it has been deployed more
	DNSSEC Signing. ECDSAP256SHA256 has seen raise in the deployment, so		widely for DNSSEC Signing. ECDSAP256SHA256 has seen raise in the
	it's set to MUST level for DNSSEC Validation.		deployment, so it's set to MUST level for DNSSEC Validation.
			ECDSAP384SHA384 offers little over ECDSAP256SHA256 and has not seen
			wide deployment, so it is at the SHOULD NOT level.
	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. Hence we expect		and it is more resilient to side-channel attacks. Hence we expect
	that those algorithms will be raised to MUST once they have been		that those algorithms will be raised to MUST once they have been
	deployed more widely.		deployed more widely.
	3.2. DS and CDS Algorithms		3.2. DS and CDS Algorithms
	skipping to change at page 8, line 22 ¶		skipping to change at page 8, line 32 ¶
	[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, DOI		Signature Algorithm (DSA) for DNSSEC", RFC 6605, DOI
	10.17487/RFC6605, April 2012,		10.17487/RFC6605, April 2012,
	<http://www.rfc-editor.org/info/rfc6605>.		<http://www.rfc-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, DOI 10.17487/		Operational Practices, Version 2", RFC 6781, DOI 10.17487/
	RFC6781, December 2012,		RFC6781, December 2012,
	<http://www.rfc-editor.org/info/rfc6781>.		<http://www.rfc-editor.org/info/rfc6781>.
			[RFC6944] Rose, S., "Applicability Statement: DNS Security (DNSSEC)
			DNSKEY Algorithm Implementation Status", RFC 6944, DOI
			10.17487/RFC6944, April 2013,
			<http://www.rfc-editor.org/info/rfc6944>.
	[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating		[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
	DNSSEC Delegation Trust Maintenance", RFC 7344, DOI		DNSSEC Delegation Trust Maintenance", RFC 7344, DOI
	10.17487/RFC7344, September 2014,		10.17487/RFC7344, September 2014,
	<http://www.rfc-editor.org/info/rfc7344>.		<http://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, DOI		"DNSSEC Key Rollover Timing Considerations", RFC 7583, DOI
	10.17487/RFC7583, October 2015,		10.17487/RFC7583, October 2015,
	<http://www.rfc-editor.org/info/rfc7583>.		<http://www.rfc-editor.org/info/rfc7583>.
End of changes. 10 change blocks.
	15 lines changed or deleted		23 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/