draft-ietf-dnsext-dnssec-2535typecode-change-03.txt   draft-ietf-dnsext-dnssec-2535typecode-change-04.txt 
INTERNET-DRAFT Samuel Weiler INTERNET-DRAFT Samuel Weiler
Expires: December 2003 June 29, 2003 Expires: February 2004 August 4, 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-03.txt draft-ietf-dnsext-dnssec-2535typecode-change-04.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 43 skipping to change at line 43
Abstract Abstract
As the DNS Security (DNSSEC) specifications have evolved, the As the DNS Security (DNSSEC) specifications have evolved, the
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 proposes that an unsecured zone to be unresolvable. This document changes the
these interactions be avoided by changing the type codes and type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to
mnemonics of the DNSSEC RRs (SIG, KEY, and NXT). avoid those interactions.
Changes between 03 and 04:
Clarified that RRSIG(0) may be defined by standards action.
Created a new algorithm registry and renamed the old algorithm
registry for SIG(0) only. Added references to the appropriate
crypto algorithm and format specifications.
Several minor rephrasings.
Changes between 02 and 03: Changes between 02 and 03:
KEY (as well as SIG) retained for SIG(0) use only. KEY (as well as SIG) retained for SIG(0) use only.
Changes between 01 and 02: Changes between 01 and 02:
SIG(0) still uses SIG, not RRSIG. Added 2931 reference. SIG(0) still uses SIG, not RRSIG. Added 2931 reference.
Domain names embedded in NSECs and RRSIGs are not compressible and Domain names embedded in NSECs and RRSIGs are not compressible and
skipping to change at line 99 skipping to change at line 109
failures makes it difficult to design and deploy a protocol change. failures makes it difficult to design and deploy a protocol change.
One strategy for managing that risk is to structure protocol One strategy for managing that risk is to structure protocol
changes so that existing resolvers can completely ignore input that changes so that existing resolvers can completely ignore input that
might confuse them or trigger undesirable failure modes. might confuse them or trigger undesirable failure modes.
This document addresses a specific problem caused by Delegation This document addresses a specific problem caused by Delegation
Signer's [DS] introduction of new semantics for the NXT RR that are Signer's [DS] introduction of new semantics for the NXT RR that are
incompatible with the semantics in RFC 2535 [RFC2535]. Answers incompatible with the semantics in RFC 2535 [RFC2535]. Answers
provided by DS-aware servers can trigger an unacceptable failure provided by DS-aware servers can trigger an unacceptable failure
mode in some resolvers that implement RFC 2535, which provides a mode in some resolvers that implement RFC 2535, which provides a
great disincentive to sign zones with DS. The proposed solution great disincentive to sign zones with DS. The changes defined in
allows 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
skipping to change at line 132 skipping to change at line 142
section, RCODE=0, and AA=0. Some widely deployed 2535-aware section, RCODE=0, and AA=0. Some widely deployed 2535-aware
resolvers interpret any answer with an NXT as a proof of resolvers interpret any answer with an NXT as a proof of
non-existence of the requested record. This results in unsecure non-existence of the requested record. This results in unsecure
delegations being invisible to 2535-aware resolvers and violates delegations being invisible to 2535-aware resolvers and violates
the basic architectural principle that DNSSEC must do no harm -- the basic architectural principle that DNSSEC must do no harm --
the signing of zones must not prevent the resolution of unsecured the signing of zones must not prevent the resolution of unsecured
delegations. delegations.
2. Possible Solutions 2. Possible Solutions
This section presents several possible solutions. Section 3 This section presents several solutions that were considered.
recommends one and describes it in more detail. Section 3 describes the one selected.
2.1. Change SIG, KEY, and NXT type codes 2.1. Change SIG, KEY, and NXT type codes
To avoid the problem described above, legacy (RFC2535-aware) To avoid the problem described above, legacy (RFC2535-aware)
resolvers need to be kept from seeing unsecure referrals that resolvers need to be kept from seeing unsecure referrals that
include NXT records in the authority section. The simplest way to include NXT records in the authority section. The simplest way to
do that is to change the type codes for SIG, KEY, and NXT. do that is to change the type codes for SIG, KEY, and NXT.
The obvious drawback to this is that new resolvers will not be able The obvious drawback to this is that new resolvers will not be able
to validate zones signed with the old RRs. This problem already to validate zones signed with the old RRs. This problem already
skipping to change at line 183 skipping to change at line 193
This solution is sufficient only if all 2535-aware resolvers zero This solution is sufficient only if all 2535-aware resolvers zero
out EDNS0 flags that they don't understand. If one passed through out EDNS0 flags that they don't understand. If one passed through
the DA bit unchanged, it would still see the new semantics, and it the DA bit unchanged, it would still see the new semantics, and it
would probably fail to see unsecure delegations. Since it's would probably fail to see unsecure delegations. Since it's
impractical to know how every DNS implementation handles unknown impractical to know how every DNS implementation handles unknown
EDNS0 flags, this is not a universal solution. It could, though, EDNS0 flags, this is not a universal solution. It could, though,
be considered in addition to changing the RR type codes. be considered in addition to changing the RR type codes.
2.4. Increment the EDNS version 2.4. Increment the EDNS version
Another proposed solution is to increment the EDNS version number Another possible solution is to increment the EDNS version number
as defined in RFC 2671 [RFC2671], on the assumption that all as defined in RFC 2671 [RFC2671], on the assumption that all
existing implementations will reject higher versions than they existing implementations will reject higher versions than they
support, and retain the DO bit as the signal for DNSSEC awareness. support, and retain the DO bit as the signal for DNSSEC awareness.
This approach has not been tested. This approach has not been tested.
2.5. Do nothing 2.5. Do nothing
There is a large deployed base of DNS resolvers that understand There is a large deployed base of DNS resolvers that understand
DNSSEC as defined by the standards track RFC 2535 and RFC 2065 DNSSEC as defined by the standards track RFC 2535 and RFC 2065
and, due to under specification in those documents, interpret any and, due to under specification in those documents, interpret any
skipping to change at line 214 skipping to change at line 224
never dies. never dies.
Rather than wait years for resolvers to be upgraded through natural Rather than wait years for resolvers to be upgraded through natural
processes before signing zones with unsecure delegations, processes before signing zones with unsecure delegations,
addressing this problem with a protocol change will immediately addressing this problem with a protocol change will immediately
remove the disincentive for signing zones and allow widespread remove the disincentive for signing zones and allow widespread
deployment of DNSSEC. deployment of DNSSEC.
3. Protocol changes 3. Protocol changes
This document proposes changing the type codes of SIG, KEY, and This document changes the type codes of SIG, KEY, and NXT. This
NXT. This approach is the cleanest and safest of those discussed approach is the cleanest and safest of those discussed above,
above, largely because the behavior of resolvers that receive largely because the behavior of resolvers that receive unknown type
unknown type codes is well understood. This approach has also codes is well understood. This approach has also received the most
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] 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 [UNKNOWN-RRs], 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. semantics. The meaning of such a resource record may only be
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 semantic value to unknown RRs and SHOULD NOT assign any special meaning to them or
them. It MUST NOT use them for DNSSEC validations or other DNS give them any special treatment. It MUST NOT use them for DNSSEC
operational decision making. For example, a resolver MUST NOT use validations or other DNS operational decision making. For example,
DNSKEYs to validate SIGs or use KEYs to validate RRSIGs. If SIG, a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to
KEY, or NXT RRs are included in a zone, they MUST NOT receive validate RRSIGs. If SIG, KEY, or NXT RRs are included in a zone,
special treatment. As an example, if a SIG is included in a signed they MUST NOT receive special treatment. As an example, if a SIG
zone, there MUST be an RRSIG for it. Authoritative servers may is included in a signed zone, there MUST be an RRSIG for it.
wish to give error messages when loading zones containing SIG or Authoritative servers may wish to give error messages when loading
NXT records (KEY records may be included for SIG(0)). zones containing SIG or NXT records (KEY records may be included
for SIG(0)).
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]
use only. Type 30 (NXT) should be marked as Obsolete. use only. Type 30 (NXT) should be marked as Obsolete.
In order to allow DNS Security and SIG(0) to use different sets of
algorithms, the existing "DNS Security Algorithm Numbers" registry
is renamed as the "SIG(0) Algorithm Numbers" registry and a new
"DNS Security Algorithm Numbers" registry is established. The
initial algorithm values are:
2 Diffie-Hellman [RFC2539]
3 DSA/SHA1 [RFC2536]
5 RSA/SHA-1 [RFC3110]
253 Private algorithms - domain name [RFC2535]
254 Private algorithms - OID [RFC2535]
Values 0, 1, and 255 are reserved. Values 4 and 6 through 252 are
available for assignment by IETF Standards Action.
It is suggested, but not required, that new algorithms usable by
both DNS Security and SIG(0) be assigned the same number in both
registries.
5. Security Considerations 5. Security Considerations
The change proposed here does not materially affect security. The The change introduced here does not materially affect security.
implications of trying to use both new and legacy types together The implications of trying to use both new and legacy types
are not well understood, and attempts to do so would probably lead together are not well understood, and attempts to do so would
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 3.1, will slow DNSSEC deployment.
While this does not decrease security, it also fails to increase While this does not decrease security, it also fails to increase
it. it.
skipping to change at line 298 skipping to change at line 329
[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-14.txt, work in
progress, May 2003. progress, May 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.
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name
System (DNS)", RFC 2436, March 1999.
[RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
Domain Name System (DNS)", RFC 2539, March 1999.
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the
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.
skipping to change at line 322 skipping to change at line 362
[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 [UNKNOWN-RRs] Gustafsson, A. Handling of Unknown DNS Resource
Record Types. draft-ietf-dnsext-unknown-rrs-05.txt Record Types. draft-ietf-dnsext-unknown-rrs-05.txt
Publication as RFC pending. Publication as RFC pending.
8. Acknowledgments 8. Acknowledgments
The proposed solution and the analysis of alternatives had many The changes introduced here and the analysis of alternatives had
contributors. With apologies to anyone overlooked, those include: many contributors. With apologies to anyone overlooked, those
Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed Lewis, include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed
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.
In addition to the above, the author would like to thank Scott In addition to the above, the author would like to thank Scott
Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive
comments. comments.
9. Author's Address 9. Author's Address
 End of changes. 

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