draft-ietf-dnsext-ds-sha256-00.txt		draft-ietf-dnsext-ds-sha256-01.txt
	Network Working Group W. Hardaker		Network Working Group W. Hardaker
	Internet-Draft Sparta		Internet-Draft Sparta
	Expires: May 14, 2006 November 10, 2005		Expires: June 2, 2006 November 29, 2005
	Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)		Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
	draft-ietf-dnsext-ds-sha256-00.txt		draft-ietf-dnsext-ds-sha256-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of 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
	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 May 14, 2006.		This Internet-Draft will expire on June 2, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document defines the use of the SHA-256 digest type for creating		This document specifies how to use the SHA-256 digest type in DNS
	digests of DNSKEY Resource Records (RRs). These digests can then be		Delegation Signer (DS) Resource Records (RRs). DS records, when
	published in Delegation Signer (DS) resource records (RRs) by a		stored in a parent zone, point to key signing DNSKEY key(s) in a
	parent zone.		child zone.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Implementing the SHA-256 algorithm for DS record support . . . 3		2. Implementing the SHA-256 algorithm for DS record support . . . 3
	2.1. DS record field values . . . . . . . . . . . . . . . . . . 3		2.1. DS record field values . . . . . . . . . . . . . . . . . . 3
	2.2. DS Record with SHA-256 Wire Format . . . . . . . . . . . . 3		2.2. DS Record with SHA-256 Wire Format . . . . . . . . . . . . 3
			2.3. Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4
	3. Implementation Requirements . . . . . . . . . . . . . . . . . . 4		3. Implementation Requirements . . . . . . . . . . . . . . . . . . 4
	4. Deployment Requirements . . . . . . . . . . . . . . . . . . . . 4		4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4		6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 5		8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
	8.2. Informative References . . . . . . . . . . . . . . . . . . 5		8.2. Informative References . . . . . . . . . . . . . . . . . . 6
	Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 5		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6		Intellectual Property and Copyright Statements . . . . . . . . . . 8
	Intellectual Property and Copyright Statements . . . . . . . . . . 7
	1. Introduction		1. Introduction
	The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published by parent		The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
	zones to distribute a cryptographic digest of a child's Key Signing		zones to distribute a cryptographic digest of a child's Key Signing
	Key (KSK) DNSKEY RR. This DS RR is signed using the parent zone's		Key (KSK) DNSKEY RR. This DS RR is signed using the parent zone's
	private half of it's DNSKEY and is published in a RRSIG record.		private half of it's DNSKEY and the signature is published in a RRSIG
			record.
	2. Implementing the SHA-256 algorithm for DS record support		2. Implementing the SHA-256 algorithm for DS record support
	This document specifies that the digest type code [XXX: To be		This document specifies that the digest type code [XXX: To be
	assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256] for		assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256] for
	use within DS records. The results of the digest algorithm MUST NOT		use within DS records. The results of the digest algorithm MUST NOT
	be truncated and the entire 32 byte digest result is to be published		be truncated and the entire 32 byte digest result is to be published
	in the DS record.		in the DS record.
	2.1. DS record field values		2.1. DS record field values
	skipping to change at page 4, line 15		skipping to change at page 4, line 15
	1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Key Tag | Algorithm | DigestType=2 |		| Key Tag | Algorithm | DigestType=2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ /		/ /
	/ Digest (length for SHA-256 is 32 bytes) /		/ Digest (length for SHA-256 is 32 bytes) /
	/ /		/ /
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
			2.3. Example DS Record Using SHA-256
			The following is an example DSKEY and matching DS record. This
			DNSKEY record comes from the example DNSKEY/DS records found in
			section 5.4 of [RFC4034].
			The DNSKEY record::
			dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
			fwJr1AYtsmx3TGkJaNXVbfi/
			2pHm822aJ5iI9BMzNXxeYCmZ
			DRD99WYwYqUSdjMmmAphXdvx
			egXd/M5+X7OrzKBaMbCVdFLU
			Uh6DhweJBjEVv5f2wwjM9Xzc
			nOf+EPbtG9DMBmADjFDc2w/r
			ljwvFw==
			) ; key id = 60485
			The resulting DS record covering the above DNSKEY record using a SHA-
			256 digest: [RFC Editor: please replace XXX with the assigned digest
			type (likely 2):]
			dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C
			CEB1E3E0614B93C4F9E99B83
			83F6A1E4469DA50A )
	3. Implementation Requirements		3. Implementation Requirements
	Implementations MUST support the use of the SHA-256 algorithm in DS		Implementations MUST support the use of the SHA-256 algorithm in DS
	RRs.		RRs.
	Implementations that support SHA-256 MUST prefer DS records with SHA-		Validator implementations MUST be able to prefer DS records
	256 (digest type number [XXX: RFC to be assigned by IANA; likely 2])		containing SHA-256 digests over those containing SHA-1 digests. This
	digests over DS records with SHA-1 (digest type number 1) digests.		behavior SHOULD by the default. Validator implementations MAY
			provide configuration settings that allow network operators to
			specify preference policy when validating multiple DS records
			containing different digest types.
	4. Deployment Requirements		4. Deployment Considerations
	Deployments SHOULD publish both SHA-1 and SHA-256 based DS records		If a validator does not support the SHA-256 digest type and no other
	for 2 years from the publication date of this RFC (XXX: RFC Editor:		DS RR exists in a zone's DS RRset with a supported digest type, then
	Please insert the calculated date here).		the validator has no supported authentication path leading from the
			parent to the child. The resolver should treat this case as it would
			the case of an authenticated NSEC RRset proving that no DS RRset
			exists, as described in [RFC4035], section 5.2.
			Because zone administrators can not control the deployment support of
			SHA-256 in deployed validators that may referencing any given zone,
			deployments should consider publishing both SHA-1 and SHA-256 based
			DS records for a while. Whether to publish both digest types
			together and for how long is a policy decision that extends beyond
			the scope of this document.
	5. IANA Considerations		5. IANA Considerations
	The Digest Type to be used for supporting SHA-256 within DS records		The Digest Type to be used for supporting SHA-256 within DS records
	needs to be assigned by IANA. This document requests that the Digest		needs to be assigned by IANA. This document requests that the Digest
	Type value of 2 be assigned to the SHA-256 digest algorithm.		Type value of 2 be assigned to the SHA-256 digest algorithm.
			At the time of this writing, the current digest types assigned for
			use in DS records are as follows:
			VALUE Digest Type Status
			0 Reserved -
			1 SHA-1 MANDATORY
			2 SHA-256 MANDATORY
			3-255 Unassigned -
	6. Security Considerations		6. Security Considerations
	Because of the weaknesses recently discovered within the SHA-1		Because of the weaknesses recently discovered within the SHA-1
	algorithm, users of DNSSEC are encouraged to deploy the use of SHA-		algorithm, users of DNSSEC are encouraged to deploy the use of SHA-
	256 as soon as software implementations in use allow for it.		256 as soon as the software implementations in use allow for it.
	At the time of this publication, the SHA-256 algorithm is considered		At the time of this publication, the SHA-256 digest algorithm is
	sufficiently strong for the immediate future. It is considered also		considered sufficiently strong for the immediate future. It is also
	considered sufficient for use in DNSSEC DS RRs for the immediate		considered sufficient for use in DNSSEC DS RRs for the immediate
	future. However, future published attacks may, of course, weaken the		future. However, future published attacks may, of course, weaken the
	usability of this algorithm within the DS RRs.		usability of this algorithm within the DS RRs. It is beyond the
			scope of this document to speculate extensively on the cryptographic
			strength of the SHA-256 digest algorithm.
			Likewise, it is also beyond the scope of this document to specify
			whether or for how long SHA-1 based DS records should be
			simultaneously published alongside SHA-256 based DS records.
	7. Acknowledgments		7. Acknowledgments
	This document is a minor extension to the existing DNSSEC documents		This document is a minor extension to the existing DNSSEC documents
	and those authors are gratefully appreciated for the hard work that		and those authors are gratefully appreciated for the hard work that
	went into the base documents.		went into the base documents.
			The following people contributed to valuable technical content of
			this document: Roy Arends, Olafur Gudmundsson, Olaf M. Kolkman, Scott
			Rose, Sam Weiler.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements",		Rose, "DNS Security Introduction and Requirements",
	RFC 4033, March 2005.		RFC 4033, March 2005.
	[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Resource Records for the DNS Security Extensions",		Rose, "Resource Records for the DNS Security Extensions",
	skipping to change at page 5, line 32		skipping to change at page 7, line 5
	[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Protocol Modifications for the DNS Security		Rose, "Protocol Modifications for the DNS Security
	Extensions", RFC 4035, March 2005.		Extensions", RFC 4035, March 2005.
	[SHA256] National Institute of Standards and Technology, "Secure		[SHA256] National Institute of Standards and Technology, "Secure
	Hash Algorithm. NIST FIPS 180-2", August 2002.		Hash Algorithm. NIST FIPS 180-2", August 2002.
	8.2. Informative References		8.2. Informative References
	Appendix A. Example
	TBD
	Author's Address		Author's Address
	Wes Hardaker		Wes Hardaker
	Sparta		Sparta
	P.O. Box 382		P.O. Box 382
	Davis 95617		Davis 95617
	US		US
	Email: hardaker@tislabs.com		Email: hardaker@tislabs.com
End of changes. 18 change blocks.
	34 lines changed or deleted		89 lines changed or added
This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/