draft-ietf-dnsext-ds-sha256-01.txt		draft-ietf-dnsext-ds-sha256-02.txt
	Network Working Group W. Hardaker		Network Working Group W. Hardaker
	Internet-Draft Sparta		Internet-Draft Sparta
	Expires: June 2, 2006 November 29, 2005		Expires: June 12, 2006 December 9, 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-01.txt		draft-ietf-dnsext-ds-sha256-02.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 June 2, 2006.		This Internet-Draft will expire on June 12, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	This document specifies how to use the SHA-256 digest type in DNS		This document specifies how to use the SHA-256 digest type in DNS
	Delegation Signer (DS) Resource Records (RRs). DS records, when		Delegation Signer (DS) Resource Records (RRs). DS records, when
	stored in a parent zone, point to key signing DNSKEY key(s) in a		stored in a parent zone, point to key signing DNSKEY key(s) in a
	skipping to change at page 3, line 9		skipping to change at page 3, line 9
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 6		8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
	8.2. Informative References . . . . . . . . . . . . . . . . . . 6		8.2. Informative References . . . . . . . . . . . . . . . . . . 6
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
	Intellectual Property and Copyright Statements . . . . . . . . . . 8		Intellectual Property and Copyright Statements . . . . . . . . . . 8
	1. Introduction		1. Introduction
	The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in 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. The DS RRset is signed by at least one of the
	private half of it's DNSKEY and the signature is published in a RRSIG		parent zone's private zone data signing keys for each algorithm in
	record.		use by the parent. Each signature is published in an RRSIG resource
			record, owned by the same domain as the DS RRset and with a type
			covered of DS.
	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 3, line 44		skipping to change at page 3, line 46
	where DNSKEY RDATA is defined by [RFC4034] as:		where DNSKEY RDATA is defined by [RFC4034] as:
	DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key		DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key
	The Key Tag field and Algorithm fields remain unchanged by this		The Key Tag field and Algorithm fields remain unchanged by this
	document and are specified in the [RFC4034] specification.		document and are specified in the [RFC4034] specification.
	2.2. DS Record with SHA-256 Wire Format		2.2. DS Record with SHA-256 Wire Format
	The resulting packet format for the resulting DS record will be [XXX:		The resulting on-the-wire format for the resulting DS record will be
	IANA assignment should replace the 2 below]:		[XXX: IANA assignment should replace the 2 below]:
	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		2.3. Example DS Record Using SHA-256
	The following is an example DSKEY and matching DS record. This		The following is an example DNSKEY and matching DS record. This
	DNSKEY record comes from the example DNSKEY/DS records found in		DNSKEY record comes from the example DNSKEY/DS records found in
	section 5.4 of [RFC4034].		section 5.4 of [RFC4034].
	The DNSKEY record::		The DNSKEY record::
	dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz		dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
	fwJr1AYtsmx3TGkJaNXVbfi/		fwJr1AYtsmx3TGkJaNXVbfi/
	2pHm822aJ5iI9BMzNXxeYCmZ		2pHm822aJ5iI9BMzNXxeYCmZ
	DRD99WYwYqUSdjMmmAphXdvx		DRD99WYwYqUSdjMmmAphXdvx
	egXd/M5+X7OrzKBaMbCVdFLU		egXd/M5+X7OrzKBaMbCVdFLU
	skipping to change at page 4, line 46		skipping to change at page 4, line 46
	dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C		dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C
	CEB1E3E0614B93C4F9E99B83		CEB1E3E0614B93C4F9E99B83
	83F6A1E4469DA50A )		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.
	Validator implementations MUST be able to prefer DS records		Validator implementations MUST, by default, ignore DS RRs containing
	containing SHA-256 digests over those containing SHA-1 digests. This		SHA-1 digests if DS RRs with SHA-256 digests are present in the DS
	behavior SHOULD by the default. Validator implementations MAY		RRset. This behavior SHOULD be the default. Validator
	provide configuration settings that allow network operators to		implementations MAY provide configuration settings that allow network
	specify preference policy when validating multiple DS records		operators to specify preference policy when validating multiple DS
	containing different digest types.		records containing different digest types.
	4. Deployment Considerations		4. Deployment Considerations
	If a validator does not support the SHA-256 digest type and no other		If a validator does not support the SHA-256 digest type and no other
	DS RR exists in a zone's DS RRset with a supported digest type, then		DS RR exists in a zone's DS RRset with a supported digest type, then
	the validator has no supported authentication path leading from the		the validator has no supported authentication path leading from the
	parent to the child. The resolver should treat this case as it would		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		the case of an authenticated NSEC RRset proving that no DS RRset
	exists, as described in [RFC4035], section 5.2.		exists, as described in [RFC4035], section 5.2.
	Because zone administrators can not control the deployment support of		Because zone administrators can not control the deployment speed of
	SHA-256 in deployed validators that may referencing any given zone,		support for SHA-256 in validators that may be referencing any of
	deployments should consider publishing both SHA-1 and SHA-256 based		their zones, zone operators should consider deploying both SHA-1 and
	DS records for a while. Whether to publish both digest types		SHA-256 based DS records. This should be done for every DNSKEY for
	together and for how long is a policy decision that extends beyond		which DS records are being generated. Whether to make use of both
	the scope of this document.		digest types 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		At the time of this writing, the current digest types assigned for
	use in DS records are as follows:		use in DS records are as follows:
	skipping to change at page 6, line 13		skipping to change at page 6, line 15
	Likewise, it is also beyond the scope of this document to specify		Likewise, it is also beyond the scope of this document to specify
	whether or for how long SHA-1 based DS records should be		whether or for how long SHA-1 based DS records should be
	simultaneously published alongside SHA-256 based DS records.		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		The following people contributed to portions of this document in some
	this document: Roy Arends, Olafur Gudmundsson, Olaf M. Kolkman, Scott		fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Olaf M.
	Rose, Sam Weiler.		Kolkman, Edward Lewis, 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.
End of changes. 9 change blocks.
	24 lines changed or deleted		27 lines changed or added
This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/