draft-ietf-dnsext-dnssec-2535typecode-change-04.txt   draft-ietf-dnsext-dnssec-2535typecode-change-05.txt 
INTERNET-DRAFT Samuel Weiler INTERNET-DRAFT Samuel Weiler
Expires: February 2004 August 4, 2003 Expires: April 2004 October 10, 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-04.txt draft-ietf-dnsext-dnssec-2535typecode-change-05.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 04 and 05:
IESG approved publication.
Cleaned up an internal reference in the acknowledgements section.
Retained KEY and SIG for TKEY, too. Added TKEY (2930) reference.
Changed the names of both new registries. Added algorithm
mnemonics to the new zone signing algorithm registry. Minor
rewording in the IANA section for clarity.
Cleaned up formatting of references. Replaced unknown-rr draft
references with RFC3597. Bumped DS version number.
Changes between 03 and 04: Changes between 03 and 04:
Clarified that RRSIG(0) may be defined by standards action. Clarified that RRSIG(0) may be defined by standards action.
Created a new algorithm registry and renamed the old algorithm Created a new algorithm registry and renamed the old algorithm
registry for SIG(0) only. Added references to the appropriate registry for SIG(0) only. Added references to the appropriate
crypto algorithm and format specifications. crypto algorithm and format specifications.
Several minor rephrasings. Several minor rephrasings.
skipping to change at line 120 skipping to change at line 135
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 this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
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 236 skipping to change at line 252
largely because the behavior of resolvers that receive unknown type largely because the behavior of resolvers that receive unknown type
codes is well understood. This approach has also received the most codes is well understood. This approach has also received the most
testing. testing.
To avoid operational confusion, it's also necessary to change the To avoid operational confusion, it's also necessary to change the
mnemonics for these RRs. DNSKEY will be the replacement for KEY, mnemonics for these RRs. DNSKEY will be the replacement for KEY,
with the mnemonic indicating that these keys are not for with the mnemonic indicating that these keys are not for
application use, per [RFC3445]. RRSIG (Resource Record SIGnature) application use, per [RFC3445]. RRSIG (Resource Record SIGnature)
will replace SIG, and NSEC (Next SECure) will replace NXT. These will replace SIG, and NSEC (Next SECure) will replace NXT. These
new types completely replace the old types, except that SIG(0) new types completely replace the old types, except that SIG(0)
[RFC2931] will continue to use SIG and KEY. [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY.
The new types will have exactly the same syntax and semantics as The new types will have exactly the same syntax and semantics as
specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for
the following: the following:
1) Consistent with [UNKNOWN-RRs], domain names embedded in 1) Consistent with [RFC3597], domain names embedded in
RRSIG and NSEC RRs MUST NOT be compressed, RRSIG and NSEC RRs MUST NOT be compressed,
2) Embedded domain names in RRSIG and NSEC RRs are not downcased 2) Embedded domain names in RRSIG and NSEC RRs are not downcased
for purposes of DNSSEC canonical form and ordering nor for for purposes of DNSSEC canonical form and ordering nor for
equality comparison, and equality comparison, and
3) An RRSIG with a type-covered field of zero has undefined 3) An RRSIG with a type-covered field of zero has undefined
semantics. The meaning of such a resource record may only be semantics. The meaning of such a resource record may only be
defined by IETF Standards Action. defined by IETF Standards Action.
If a resolver receives the old types, it SHOULD treat them as If a resolver receives the old types, it SHOULD treat them as
unknown RRs and SHOULD NOT assign any special meaning to them or unknown RRs and SHOULD NOT assign any special meaning to them or
give them any special treatment. It MUST NOT use them for DNSSEC give them any special treatment. It MUST NOT use them for DNSSEC
validations or other DNS operational decision making. For example, validations or other DNS operational decision making. For example,
a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to
validate RRSIGs. If SIG, KEY, or NXT RRs are included in a zone, validate RRSIGs. If SIG, KEY, or NXT RRs are included in a zone,
they MUST NOT receive special treatment. As an example, if a SIG they MUST NOT receive special treatment. As an example, if a SIG
is included in a signed zone, there MUST be an RRSIG for it. is included in a signed zone, there MUST be an RRSIG for it.
Authoritative servers may wish to give error messages when loading Authoritative servers may wish to give error messages when loading
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)). 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
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] Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
use only. Type 30 (NXT) should be marked as Obsolete. TKEY [RFC2930] use only. Type 30 (NXT) should be marked as
Obsolete.
In order to allow DNS Security and SIG(0) to use different sets of In order to allow zone signing (DNSSEC) and transaction security
algorithms, the existing "DNS Security Algorithm Numbers" registry mechanisms (SIG(0) and TKEY) to use different sets of algorithms,
is renamed as the "SIG(0) Algorithm Numbers" registry and a new the existing "DNS Security Algorithm Numbers" is deprecated. All
"DNS Security Algorithm Numbers" registry is established. The of its existing assignments are copied into the new "DNS
initial algorithm values are: Transaction Security Algorithm Numbers" registry. A new "DNS Zone
Signing Algorithm Numbers" registry is established with initial
assignments of:
2 Diffie-Hellman [RFC2539] Value Algorithm Mnemonic Reference
3 DSA/SHA1 [RFC2536] 0 reserved
5 RSA/SHA-1 [RFC3110] 1 reserved
253 Private algorithms - domain name [RFC2535] 2 Diffie-Hellman DH [RFC2539]
254 Private algorithms - OID [RFC2535] 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 0, 1, and 255 are reserved. Values 4 and 6 through 252 are Values 4 and 6 through 252 are available for assignment by IETF
available for assignment by IETF Standards Action. Standards Action.
It is suggested, but not required, that new algorithms usable by If a new algorithm is usable for both zone signing (DNSSEC) and
both DNS Security and SIG(0) be assigned the same number in both SIG(0)/TKEY, it is suggested, but not required, that it be assigned
registries. the same number in both registries.
5. Security Considerations 5. Security Considerations
The change introduced here does not materially affect security. The change introduced here does 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 3.1, will slow DNSSEC deployment. Doing nothing, as described in section 2.5, will slow DNSSEC
While this does not decrease security, it also fails to increase deployment. While this does not decrease security, it also fails
it. to increase it.
6. Normative references 6. Normative references
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
[DS] Gudmundsson, O., "Delegation Signer Resource Record", [DS] Gudmundsson, O., "Delegation Signer Resource Record",
draft-ietf-dnsext-delegation-signer-14.txt, work in draft-ietf-dnsext-delegation-signer-15.txt, work in
progress, May 2003. progress, June 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
(SIG(0)s)", RFC 2931, September 2000. (SIG(0)s)", RFC 2931, September 2000.
[RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
RR)", RFC 2930, September 2000.
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name
System (DNS)", RFC 2436, March 1999. System (DNS)", RFC 2436, March 1999.
[RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
Domain Name System (DNS)", RFC 2539, March 1999. Domain Name System (DNS)", RFC 2539, March 1999.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the
Domain Name System (DNS)", RFC 3110, May 2001. Domain Name System (DNS)", RFC 3110, May 2001.
7. Informative References 7. Informative References
[RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
Extensions", RFC 2065, January 1997. Extensions", RFC 2065, January 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999. 2671, August 1999.
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
3225, December 2001. 3225, December 2001.
[RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning. [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning,
Domain Name System (DNS) IANA Considerations. BCP 42, "Domain Name System (DNS) IANA Considerations", BCP 42,
RFC 2929, September 2000. RFC 2929, September 2000.
[RFC3445] Massey, D., and S. Rose. Limiting the Scope of the KEY [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR). RFC 3445, December 2002. Resource Record (RR)", RFC 3445, December 2002.
[UNKNOWN-RRs] Gustafsson, A. Handling of Unknown DNS Resource [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
Record Types. draft-ietf-dnsext-unknown-rrs-05.txt Record (RR) Types", RFC 3597, September 2003.
Publication as RFC pending.
8. Acknowledgments 8. Acknowledgments
The changes introduced here and the analysis of alternatives had The changes introduced here and the analysis of alternatives had
many contributors. With apologies to anyone overlooked, those many contributors. With apologies to anyone overlooked, those
include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed
Lewis, Bill Manning, and Suzanne Woolf. Lewis, Bill Manning, and Suzanne Woolf.
Thanks to Jakob Schlyter and Mark Andrews for identifying the Thanks to Jakob Schlyter and Mark Andrews for identifying the
incompatibility described in section 1.2. incompatibility described in section 1.2.
 End of changes. 

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