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. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/