< draft-ietf-dnsext-dnssec-2535typecode-change-05.txt		draft-ietf-dnsext-dnssec-2535typecode-change-06.txt >
	INTERNET-DRAFT Samuel Weiler		INTERNET-DRAFT Samuel Weiler
	Expires: April 2004 October 10, 2003		Expires: June 2004 December 15, 2003
	Updates: RFC 2535, [DS]		Updates: RFC 2535, [DS]
	Legacy Resolver Compatibility for Delegation Signer		Legacy Resolver Compatibility for Delegation Signer
	draft-ietf-dnsext-dnssec-2535typecode-change-05.txt		draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of Section 10 of RFC2026.		of Section 10 of RFC2026.
	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		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at line 47 ¶		skipping to change at line 47 ¶
	syntax and semantics of the DNSSEC resource records (RRs) have		syntax and semantics of the DNSSEC resource records (RRs) have
	changed. Many deployed nameservers understand variants of these		changed. Many deployed nameservers understand variants of these
	semantics. Dangerous interactions can occur when a resolver that		semantics. Dangerous interactions can occur when a resolver that
	understands an earlier version of these semantics queries an		understands an earlier version of these semantics queries an
	authoritative server that understands the new delegation signer		authoritative server that understands the new delegation signer
	semantics, including at least one failure scenario that will cause		semantics, including at least one failure scenario that will cause
	an unsecured zone to be unresolvable. This document changes the		an unsecured zone to be unresolvable. This document changes the
	type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to		type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to
	avoid those interactions.		avoid those interactions.
			Changes between 05 and 06:
			Signifigantly reworked the IANA section -- went back to one
			algorithm registry.
			Removed Diffie-Hellman from the list of zone-signing algorithms
			(leaving only DSA, RSA/SHA-1, and private algorithms).
			Added a DNSKEY flags field registry.
	Changes between 04 and 05:		Changes between 04 and 05:
	IESG approved publication.		IESG approved publication.
	Cleaned up an internal reference in the acknowledgements section.		Cleaned up an internal reference in the acknowledgements section.
	Retained KEY and SIG for TKEY, too. Added TKEY (2930) reference.		Retained KEY and SIG for TKEY, too. Added TKEY (2930) reference.
	Changed the names of both new registries. Added algorithm		Changed the names of both new registries. Added algorithm
	mnemonics to the new zone signing algorithm registry. Minor		mnemonics to the new zone signing algorithm registry. Minor
	skipping to change at line 135 ¶		skipping to change at line 145 ¶
	this document allow for the incremental deployment of DS.		this document allow for the incremental deployment of DS.
	1.1 Terminology		1.1 Terminology
	In this document, the term "unsecure delegation" means any		In this document, the term "unsecure delegation" means any
	delegation for which no DS record appears at the parent. An		delegation for which no DS record appears at the parent. An
	"unsecure referral" is an answer from the parent containing an NS		"unsecure referral" is an answer from the parent containing an NS
	RRset and a proof that no DS record exists for that name.		RRset and a proof that no DS record exists for that name.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	1.2 The Problem		1.2 The Problem
	Delegation Signer introduces new semantics for the NXT RR that are		Delegation Signer introduces new semantics for the NXT RR that are
	incompatible with the semantics in RFC 2535. In RFC 2535, NXT		incompatible with the semantics in RFC 2535. In RFC 2535, NXT
	records were only required to be returned as part of a		records were only required to be returned as part of a
	non-existence proof. With DS, an unsecure referral returns, in		non-existence proof. With DS, an unsecure referral returns, in
	addition to the NS, a proof of non-existence of a DS RR in the form		addition to the NS, a proof of non-existence of a DS RR in the form
	of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was		of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was
	skipping to change at line 288 ¶		skipping to change at line 297 ¶
	zones containing SIG or NXT records (KEY records may be included		zones containing SIG or NXT records (KEY records may be included
	for SIG(0) or TKEY).		for SIG(0) or TKEY).
	As a clarification to previous documents, some positive responses,		As a clarification to previous documents, some positive responses,
	particularly wildcard proofs and unsecure referrals, will contain		particularly wildcard proofs and unsecure referrals, will contain
	NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as		NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as
	negative answers merely because they contain an NSEC.		negative answers merely because they contain an NSEC.
	4. IANA Considerations		4. IANA Considerations
			4.1 DNS Resource Record Types
	This document updates the IANA registry for DNS Resource Record		This document updates the IANA registry for DNS Resource Record
	Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and		Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and
	DNSKEY RRs, respectively.		DNSKEY RRs, respectively.
	Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and		Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
	TKEY [RFC2930] use only. Type 30 (NXT) should be marked as		TKEY [RFC2930] use only.
	Obsolete.
	In order to allow zone signing (DNSSEC) and transaction security		Type 30 (NXT) should be marked as Obsolete.
	mechanisms (SIG(0) and TKEY) to use different sets of algorithms,
	the existing "DNS Security Algorithm Numbers" is deprecated. All
	of its existing assignments are copied into the new "DNS
	Transaction Security Algorithm Numbers" registry. A new "DNS Zone
	Signing Algorithm Numbers" registry is established with initial
	assignments of:
	Value Algorithm Mnemonic Reference		4.2 DNS Security Algorithm Numbers
	0 reserved
	1 reserved
	2 Diffie-Hellman DH [RFC2539]
	3 DSA/SHA-1 DSA [RFC2536]
	5 RSA/SHA-1 HEDGEHOG [RFC3110]
	253 Private algorithms - domain name PRIVATEDNS [RFC2535]
	254 Private algorithms - OID PRIVATEOID [RFC2535]
	255 reserved
	Values 4 and 6 through 252 are available for assignment by IETF		To allow zone signing (DNSSEC) and transaction security mechanisms
			(SIG(0) and TKEY) to use different sets of algorithms, the existing
			"DNS Security Algorithm Numbers" registry is modified to include
			the applicability of each algorithm. Specifically, two new columns
			are added to the registry, showing whether each algorithm may be
			used for zone signing, transaction security mechanisms, or both.
			Only algorithms usable for zone signing may be used in DNSKEY,
			RRSIG, and DS RRs. Only algorithms usable for SIG(0) and/or TSIG
			may be used in SIG and KEY RRs.
			All currently defined algorithms remain usable for transaction
			security mechanisms. Only RSA/SHA-1, DSA/SHA-1, and private
			algorithms (types 253 and 254) may be used for zone signing. Note
			that the registry does not contain the requirement level of each
			algorithm, only whether or not an algorithm may be used for the
			given purposes. For example, RSA/MD5, while allowed for
			transaction security mechanisms, is NOT RECOMMENDED, per RFC3110.
			Additionally, the presentation format algorithm mnemonics from
			RFC2535 Section 7 are added to the registry. This document assigns
			RSA/SHA-1 the mnemonic RSASHA1.
			As before, assignment of new algorithms in this registry requires
			IETF Standards Action. Additionally, modification of algorithm
			mnemonics or applicability requires IETF Standards Action.
			Documents defining a new algorithm must address the applicability
			of the algorithm and should assign a presentation mnemonic to the
			algorithm.
			4.3 DNSKEY Flags
			Like the KEY resource record, DNSKEY contains a 16-bit flags field.
			This document creates a new registry for the DNSKEY flags field.
			Initially, this registry only contains an assignment for bit 7 (the
			ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF
	Standards Action.		Standards Action.
	If a new algorithm is usable for both zone signing (DNSSEC) and		4.4 DNSKEY Protocol Octet
	SIG(0)/TKEY, it is suggested, but not required, that it be assigned
	the same number in both registries.		Like the KEY resource record, DNSKEY contains an eight bit protocol
			field. The only defined value for this field is 3 (DNSSEC). No
			other values are allowed, hence no IANA registry is needed for this
			field.
	5. Security Considerations		5. Security Considerations
	The change introduced here does not materially affect security.		The changes introduced here do not materially affect security.
	The implications of trying to use both new and legacy types		The implications of trying to use both new and legacy types
	together are not well understood, and attempts to do so would		together are not well understood, and attempts to do so would
	probably lead to unintended and dangerous results.		probably lead to unintended and dangerous results.
	Changing type codes will leave code paths in legacy resolvers that		Changing type codes will leave code paths in legacy resolvers that
	are never exercised. Unexercised code paths are a frequent source		are never exercised. Unexercised code paths are a frequent source
	of security holes, largely because those code paths do not get		of security holes, largely because those code paths do not get
	frequent scrutiny.		frequent scrutiny.
	Doing nothing, as described in section 2.5, will slow DNSSEC		Doing nothing, as described in section 2.5, will slow DNSSEC
End of changes. 11 change blocks.
	27 lines changed or deleted		61 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/