443 lines
18 KiB
Plaintext
443 lines
18 KiB
Plaintext
|
|
|
|
INTERNET-DRAFT Samuel Weiler
|
|
Expires: June 2004 December 15, 2003
|
|
Updates: RFC 2535, [DS]
|
|
|
|
Legacy Resolver Compatibility for Delegation Signer
|
|
draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
|
|
|
|
Status of this Memo
|
|
|
|
This document is an Internet-Draft and is subject to all provisions
|
|
of Section 10 of RFC2026.
|
|
|
|
Internet-Drafts are working documents of the Internet Engineering
|
|
Task Force (IETF), its areas, and its working groups. Note that
|
|
other groups may also distribute working documents as
|
|
Internet-Drafts.
|
|
|
|
Internet-Drafts are draft documents valid for a maximum of six
|
|
months and may be updated, replaced, or obsoleted by other
|
|
documents at any time. It is inappropriate to use Internet-Drafts
|
|
as reference material or to cite them other than as "work in
|
|
progress."
|
|
|
|
The list of current Internet-Drafts can be accessed at
|
|
http://www.ietf.org/1id-abstracts.html
|
|
|
|
The list of Internet-Draft Shadow Directories can be accessed at
|
|
http://www.ietf.org/shadow.html
|
|
|
|
Comments should be sent to the author or to the DNSEXT WG mailing
|
|
list: namedroppers@ops.ietf.org
|
|
|
|
Abstract
|
|
|
|
As the DNS Security (DNSSEC) specifications have evolved, the
|
|
syntax and semantics of the DNSSEC resource records (RRs) have
|
|
changed. Many deployed nameservers understand variants of these
|
|
semantics. Dangerous interactions can occur when a resolver that
|
|
understands an earlier version of these semantics queries an
|
|
authoritative server that understands the new delegation signer
|
|
semantics, including at least one failure scenario that will cause
|
|
an unsecured zone to be unresolvable. This document changes the
|
|
type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to
|
|
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:
|
|
|
|
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:
|
|
|
|
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:
|
|
|
|
KEY (as well as SIG) retained for SIG(0) use only.
|
|
|
|
Changes between 01 and 02:
|
|
|
|
SIG(0) still uses SIG, not RRSIG. Added 2931 reference.
|
|
|
|
Domain names embedded in NSECs and RRSIGs are not compressible and
|
|
are not downcased. Added unknown-rrs reference (as informative).
|
|
|
|
Simplified the last paragraph of section 3 (NSEC doesn't always
|
|
signal a negative answer).
|
|
|
|
Changed the suggested type code assignments.
|
|
|
|
Added 2119 reference.
|
|
|
|
Added definitions of "unsecure delegation" and "unsecure referral",
|
|
since they're not clearly defined elsewhere.
|
|
|
|
Moved 2065 to informative references, not normative.
|
|
|
|
1. Introduction
|
|
|
|
The DNSSEC protocol has been through many iterations whose syntax
|
|
and semantics are not completely compatible. This has occurred as
|
|
part of the ordinary process of proposing a protocol, implementing
|
|
it, testing it in the increasingly complex and diverse environment
|
|
of the Internet, and refining the definitions of the initial
|
|
Proposed Standard. In the case of DNSSEC, the process has been
|
|
complicated by DNS's criticality and wide deployment and the need
|
|
to add security while minimizing daily operational complexity.
|
|
|
|
A weak area for previous DNS specifications has been lack of detail
|
|
in specifying resolver behavior, leaving implementors largely on
|
|
their own to determine many details of resolver function. This,
|
|
combined with the number of iterations the DNSSEC spec has been
|
|
through, has resulted in fielded code with a wide variety of
|
|
behaviors. This variety makes it difficult to predict how a
|
|
protocol change will be handled by all deployed resolvers. The
|
|
risk that a change will cause unacceptable or even catastrophic
|
|
failures makes it difficult to design and deploy a protocol change.
|
|
One strategy for managing that risk is to structure protocol
|
|
changes so that existing resolvers can completely ignore input that
|
|
might confuse them or trigger undesirable failure modes.
|
|
|
|
This document addresses a specific problem caused by Delegation
|
|
Signer's [DS] introduction of new semantics for the NXT RR that are
|
|
incompatible with the semantics in RFC 2535 [RFC2535]. Answers
|
|
provided by DS-aware servers can trigger an unacceptable failure
|
|
mode in some resolvers that implement RFC 2535, which provides a
|
|
great disincentive to sign zones with DS. The changes defined in
|
|
this document allow for the incremental deployment of DS.
|
|
|
|
1.1 Terminology
|
|
|
|
In this document, the term "unsecure delegation" means any
|
|
delegation for which no DS record appears at the parent. An
|
|
"unsecure referral" is an answer from the parent containing an NS
|
|
RRset and a proof that no DS record exists for that name.
|
|
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|
document are to be interpreted as described in [RFC2119].
|
|
|
|
1.2 The Problem
|
|
|
|
Delegation Signer introduces new semantics for the NXT RR that are
|
|
incompatible with the semantics in RFC 2535. In RFC 2535, NXT
|
|
records were only required to be returned as part of a
|
|
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
|
|
of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was
|
|
to interpret a response with both an NS and an NXT in the authority
|
|
section, RCODE=0, and AA=0. Some widely deployed 2535-aware
|
|
resolvers interpret any answer with an NXT as a proof of
|
|
non-existence of the requested record. This results in unsecure
|
|
delegations being invisible to 2535-aware resolvers and violates
|
|
the basic architectural principle that DNSSEC must do no harm --
|
|
the signing of zones must not prevent the resolution of unsecured
|
|
delegations.
|
|
|
|
2. Possible Solutions
|
|
|
|
This section presents several solutions that were considered.
|
|
Section 3 describes the one selected.
|
|
|
|
2.1. Change SIG, KEY, and NXT type codes
|
|
|
|
To avoid the problem described above, legacy (RFC2535-aware)
|
|
resolvers need to be kept from seeing unsecure referrals that
|
|
include NXT records in the authority section. The simplest way to
|
|
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
|
|
to validate zones signed with the old RRs. This problem already
|
|
exists, however, because of the changes made by DS, and resolvers
|
|
that understand the old RRs (and have compatibility issues with DS)
|
|
are far more prevalent than 2535-signed zones.
|
|
|
|
2.2. Change a subset of type codes
|
|
|
|
The observed problem with unsecure referrals could be addressed by
|
|
changing only the NXT type code or another subset of the type codes
|
|
that includes NXT. This has the virtue of apparent simplicity, but
|
|
it risks introducing new problems or not going far enough. It's
|
|
quite possible that more incompatibilities exist between DS and
|
|
earlier semantics. Legacy resolvers may also be confused by seeing
|
|
records they recognize (SIG and KEY) while being unable to find
|
|
NXTs. Although it may seem unnecessary to fix that which is not
|
|
obviously broken, it's far cleaner to change all of the type codes
|
|
at once. This will leave legacy resolvers and tools completely
|
|
blinded to DNSSEC -- they will see only unknown RRs.
|
|
|
|
2.3. Replace the DO bit
|
|
|
|
Another way to keep legacy resolvers from ever seeing DNSSEC
|
|
records with DS semantics is to have authoritative servers only
|
|
send that data to DS-aware resolvers. It's been proposed that
|
|
assigning a new EDNS0 flag bit to signal DS-awareness (tentatively
|
|
called "DA"), and having authoritative servers send DNSSEC data
|
|
only in response to queries with the DA bit set, would accomplish
|
|
this. This bit would presumably supplant the DO bit described in
|
|
RFC 3225.
|
|
|
|
This solution is sufficient only if all 2535-aware resolvers zero
|
|
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
|
|
would probably fail to see unsecure delegations. Since it's
|
|
impractical to know how every DNS implementation handles unknown
|
|
EDNS0 flags, this is not a universal solution. It could, though,
|
|
be considered in addition to changing the RR type codes.
|
|
|
|
2.4. Increment the EDNS version
|
|
|
|
Another possible solution is to increment the EDNS version number
|
|
as defined in RFC 2671 [RFC2671], on the assumption that all
|
|
existing implementations will reject higher versions than they
|
|
support, and retain the DO bit as the signal for DNSSEC awareness.
|
|
This approach has not been tested.
|
|
|
|
2.5. Do nothing
|
|
|
|
There is a large deployed base of DNS resolvers that understand
|
|
DNSSEC as defined by the standards track RFC 2535 and RFC 2065
|
|
and, due to under specification in those documents, interpret any
|
|
answer with an NXT as a non-existence proof. So long as that is
|
|
the case, zone owners will have a strong incentive to not sign any
|
|
zones that contain unsecure delegations, lest those delegations be
|
|
invisible to such a large installed base. This will dramatically
|
|
slow DNSSEC adoption.
|
|
|
|
Unfortunately, without signed zones there's no clear incentive for
|
|
operators of resolvers to upgrade their software to support the new
|
|
version of DNSSEC, as defined in [DS]. Historical data suggests
|
|
that resolvers are rarely upgraded, and that old nameserver code
|
|
never dies.
|
|
|
|
Rather than wait years for resolvers to be upgraded through natural
|
|
processes before signing zones with unsecure delegations,
|
|
addressing this problem with a protocol change will immediately
|
|
remove the disincentive for signing zones and allow widespread
|
|
deployment of DNSSEC.
|
|
|
|
3. Protocol changes
|
|
|
|
This document changes the type codes of SIG, KEY, and NXT. This
|
|
approach is the cleanest and safest of those discussed above,
|
|
largely because the behavior of resolvers that receive unknown type
|
|
codes is well understood. This approach has also received the most
|
|
testing.
|
|
|
|
To avoid operational confusion, it's also necessary to change the
|
|
mnemonics for these RRs. DNSKEY will be the replacement for KEY,
|
|
with the mnemonic indicating that these keys are not for
|
|
application use, per [RFC3445]. RRSIG (Resource Record SIGnature)
|
|
will replace SIG, and NSEC (Next SECure) will replace NXT. These
|
|
new types completely replace the old types, except that SIG(0)
|
|
[RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY.
|
|
|
|
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
|
|
the following:
|
|
|
|
1) Consistent with [RFC3597], domain names embedded in
|
|
RRSIG and NSEC RRs MUST NOT be compressed,
|
|
|
|
2) Embedded domain names in RRSIG and NSEC RRs are not downcased
|
|
for purposes of DNSSEC canonical form and ordering nor for
|
|
equality comparison, and
|
|
|
|
3) An RRSIG with a type-covered field of zero has undefined
|
|
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
|
|
unknown RRs and SHOULD NOT assign any special meaning to them or
|
|
give them any special treatment. It MUST NOT use them for DNSSEC
|
|
validations or other DNS operational decision making. For example,
|
|
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,
|
|
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.
|
|
Authoritative servers may wish to give error messages when loading
|
|
zones containing SIG or NXT records (KEY records may be included
|
|
for SIG(0) or TKEY).
|
|
|
|
As a clarification to previous documents, some positive responses,
|
|
particularly wildcard proofs and unsecure referrals, will contain
|
|
NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as
|
|
negative answers merely because they contain an NSEC.
|
|
|
|
4. IANA Considerations
|
|
|
|
4.1 DNS Resource Record Types
|
|
|
|
This document updates the IANA registry for DNS Resource Record
|
|
Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and
|
|
DNSKEY RRs, respectively.
|
|
|
|
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 Obsolete.
|
|
|
|
4.2 DNS Security Algorithm Numbers
|
|
|
|
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.
|
|
|
|
4.4 DNSKEY Protocol Octet
|
|
|
|
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
|
|
|
|
The changes introduced here do not materially affect security.
|
|
The implications of trying to use both new and legacy types
|
|
together are not well understood, and attempts to do so would
|
|
probably lead to unintended and dangerous results.
|
|
|
|
Changing type codes will leave code paths in legacy resolvers that
|
|
are never exercised. Unexercised code paths are a frequent source
|
|
of security holes, largely because those code paths do not get
|
|
frequent scrutiny.
|
|
|
|
Doing nothing, as described in section 2.5, will slow DNSSEC
|
|
deployment. While this does not decrease security, it also fails
|
|
to increase it.
|
|
|
|
6. Normative references
|
|
|
|
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
|
|
RFC 2535, March 1999.
|
|
|
|
[DS] Gudmundsson, O., "Delegation Signer Resource Record",
|
|
draft-ietf-dnsext-delegation-signer-15.txt, work in
|
|
progress, June 2003.
|
|
|
|
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|
|
|
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
|
|
(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
|
|
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
|
|
|
|
[RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
|
|
Extensions", RFC 2065, January 1997.
|
|
|
|
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
|
|
2671, August 1999.
|
|
|
|
[RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
|
|
3225, December 2001.
|
|
|
|
[RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning,
|
|
"Domain Name System (DNS) IANA Considerations", BCP 42,
|
|
RFC 2929, September 2000.
|
|
|
|
[RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
|
|
Resource Record (RR)", RFC 3445, December 2002.
|
|
|
|
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
|
|
Record (RR) Types", RFC 3597, September 2003.
|
|
|
|
8. Acknowledgments
|
|
|
|
The changes introduced here and the analysis of alternatives had
|
|
many contributors. With apologies to anyone overlooked, those
|
|
include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed
|
|
Lewis, Bill Manning, and Suzanne Woolf.
|
|
|
|
Thanks to Jakob Schlyter and Mark Andrews for identifying the
|
|
incompatibility described in section 1.2.
|
|
|
|
In addition to the above, the author would like to thank Scott
|
|
Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive
|
|
comments.
|
|
|
|
9. Author's Address
|
|
|
|
Samuel Weiler
|
|
SPARTA, Inc.
|
|
7075 Samuel Morse Drive
|
|
Columbia, MD 21046
|
|
USA
|
|
weiler@tislabs.com
|
|
|