draft-ietf-dnsext-dnssec-rsasha256-11.txt		draft-ietf-dnsext-dnssec-rsasha256-12.txt
	DNS Extensions working group J. Jansen		DNS Extensions working group J. Jansen
	Internet-Draft NLnet Labs		Internet-Draft NLnet Labs
	Intended status: Standards Track February 27, 2009		Intended status: Standards Track March 23, 2009
	Expires: August 31, 2009		Expires: September 24, 2009
	Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records		Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records
	for DNSSEC		for DNSSEC
	draft-ietf-dnsext-dnssec-rsasha256-11		draft-ietf-dnsext-dnssec-rsasha256-12
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 33		skipping to change at page 1, line 33
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 31, 2009.		This Internet-Draft will expire on September 24, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 5, line 29		skipping to change at page 5, line 29
	Apart from the restrictions in section 2, this document will not		Apart from the restrictions in section 2, this document will not
	specify what size of keys to use. That is an operational issue and		specify what size of keys to use. That is an operational issue and
	depends largely on the environment and intended use. A good starting		depends largely on the environment and intended use. A good starting
	point for more information would be NIST SP 800-57 [NIST800-57].		point for more information would be NIST SP 800-57 [NIST800-57].
	4.2. Signature Sizes		4.2. Signature Sizes
	In this family of signing algorithms, the size of signatures is		In this family of signing algorithms, the size of signatures is
	related to the size of the key, and not the hashing algorithm used in		related to the size of the key, and not the hashing algorithm used in
	the signing process. Therefore, RRSIG resource records produced with		the signing process. Therefore, RRSIG resource records produced with
	RSA/SHA256 or RSA/SHA512 will have the same size as those produced		RSA/SHA-256 or RSA/SHA-512 will have the same size as those produced
	with RSA/SHA1, if the keys have the same length.		with RSA/SHA-1, if the keys have the same length.
	5. Implementation Considerations		5. Implementation Considerations
	5.1. Support for SHA-2 signatures		5.1. Support for SHA-2 signatures
	DNSSEC aware implementations SHOULD be able to support RRSIG and		DNSSEC aware implementations SHOULD be able to support RRSIG and
	DNSKEY resource records created with the RSA/SHA-2 algorithms as		DNSKEY resource records created with the RSA/SHA-2 algorithms as
	defined in this document.		defined in this document.
	5.2. Support for NSEC3 Denial of Existence		5.2. Support for NSEC3 Denial of Existence
	RFC5155 [RFC5155] defines new algorithm identifiers for existing		RFC5155 [RFC5155] defines new algorithm identifiers for existing
	signing algorithms, to indicate that zones signed with these		signing algorithms, to indicate that zones signed with these
	algorithm identifiers use NSEC3 instead of NSEC records to provide		algorithm identifiers can use NSEC3 as well as NSEC records to
	denial of existence. That mechanism was chosen to protect		provide denial of existence. That mechanism was chosen to protect
	implementations predating RFC5155 from encountering resource records		implementations predating RFC5155 from encountering resource records
	they could not know about. This document does not define such		they could not know about. This document does not define such
	algorithm aliases, and support for NSEC3 denial of existence is		algorithm aliases, and support for NSEC3 denial of existence is
	implicitly signaled with support for one of the algorithms defined in		implicitly signaled with support for one of the algorithms defined in
	this document.		this document.
	5.2.1. NSEC3 in Authoritative servers		5.2.1. NSEC3 in Authoritative servers
	An authoritative server that does not implement NSEC3 MAY still serve		An authoritative server that does not implement NSEC3 MAY still serve
	zones that use RSA/SHA2 with NSEC denial of existence.		zones that use RSA/SHA-2 with NSEC denial of existence.
	5.2.2. NSEC3 in Validators		5.2.2. NSEC3 in Validators
	A DNSSEC validator that implements RSA/SHA2 MUST be able to handle		A DNSSEC validator that implements RSA/SHA-2 MUST be able to handle
	both NSEC and NSEC3 [RFC5155] negative answers. If this is not the		both NSEC and NSEC3 [RFC5155] negative answers. If this is not the
	case, the validator MUST treat a zone signed with RSA/SHA256 or RSA/		case, the validator MUST treat a zone signed with RSA/SHA-256 or RSA/
	SHA512 as signed with an unknown algorithm, and thus as insecure.		SHA-512 as signed with an unknown algorithm, and thus as insecure.
	6. IANA Considerations		6. IANA Considerations
	This document updates the IANA registry "DNS SECURITY ALGORITHM		This document updates the IANA registry "DNS SECURITY ALGORITHM
	NUMBERS -- per [RFC4035] "		NUMBERS -- per [RFC4035] "
	(http://www.iana.org/assignments/dns-sec-alg-numbers). The following		(http://www.iana.org/assignments/dns-sec-alg-numbers). The following
	entries are added to the registry:		entries are added to the registry:
	Zone		Zone Trans.
	Value Algorithm Mnemonic Signing References		Value Description Mnemonic Signing Sec. References
	{TBA1} RSA/SHA-256 RSASHA256 y {this memo}		{TBA1} RSA/SHA-256 RSASHA256 y * {this memo}
	{TBA2} RSA/SHA-512 RSASHA512 y {this memo}		{TBA2} RSA/SHA-512 RSASHA512 y * {this memo}
			* There has been no determination of standardization of the use of this
			algorithm with Transaction Security.
	7. Security Considerations		7. Security Considerations
	7.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource Records		7.1. SHA-1 versus SHA-2 Considerations for RRSIG Resource Records
	Users of DNSSEC are encouraged to deploy SHA-2 as soon as software		Users of DNSSEC are encouraged to deploy SHA-2 as soon as software
	implementations allow for it. SHA-2 is widely believed to be more		implementations allow for it. SHA-2 is widely believed to be more
	resilient to attack than SHA-1, and confidence in SHA-1's strength is		resilient to attack than SHA-1, and confidence in SHA-1's strength is
	being eroded by recently-announced attacks. Regardless of whether or		being eroded by recently-announced attacks. Regardless of whether or
	not the attacks on SHA-1 will affect DNSSEC, it is believed (at the		not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
End of changes. 9 change blocks.
	16 lines changed or deleted		19 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/