draft-ietf-dnsext-delegation-signer-10.txt   draft-ietf-dnsext-delegation-signer-11.txt 
DNSEXT Working Group Olafur Gudmundsson DNSEXT Working Group Olafur Gudmundsson
<draft-ietf-dnsext-delegation-signer-10.txt> <draft-ietf-dnsext-delegation-signer-11.txt>
Updates: RFC 1035, RFC 2535, RFC 3008, RFC 3090. Updates: RFC 1035, RFC 2535, RFC 3008, RFC 3090.
Delegation Signer Resource Record Delegation Signer Resource Record
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Comments should be sent to the authors or the DNSEXT WG mailing list Comments should be sent to the authors or the DNSEXT WG mailing list
namedroppers@ops.ietf.org namedroppers@ops.ietf.org
This draft expires on April 16, 2003. This draft expires on April 30, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All rights reserved. Copyright (C) The Internet Society (2002). All rights reserved.
Abstract Abstract
The delegation signer (DS) resource record is inserted at a zone cut The delegation signer (DS) resource record is inserted at a zone cut
(i.e., a delegation point) to indicate that the delegated zone is (i.e., a delegation point) to indicate that the delegated zone is
digitally signed and that the delegated zone recognizes the indicated digitally signed and that the delegated zone recognizes the indicated
skipping to change at page 2, line 37 skipping to change at page 2, line 37
registry requirements. registry requirements.
DNSSEC [RFC2535,RFC3008,RFC3090] specifies that a child zone needs to DNSSEC [RFC2535,RFC3008,RFC3090] specifies that a child zone needs to
have its KEY RRset signed by its parent to create a verifiable chain have its KEY RRset signed by its parent to create a verifiable chain
of KEYs. There has been some debate on where the signed KEY RRset of KEYs. There has been some debate on where the signed KEY RRset
should reside, whether at the child [RFC2535] or at the parent. If should reside, whether at the child [RFC2535] or at the parent. If
the KEY RRset resides at the child, maintaining the signed KEY RRset the KEY RRset resides at the child, maintaining the signed KEY RRset
in the child requires frequent two-way communication between the two in the child requires frequent two-way communication between the two
parties. First the child transmits the KEY RRset to the parent and parties. First the child transmits the KEY RRset to the parent and
then the parent sends the signature(s) to the child. Storing the KEY then the parent sends the signature(s) to the child. Storing the KEY
RRset at the parent simplifies the communication. RRset at the parent was thought to simplify the communication.
DNSSEC [RFC2535] requires that the parent store a NULL KEY record for DNSSEC [RFC2535] requires that the parent store a NULL KEY record for
an unsecure child zone to indicate that the child is unsecure. A NULL an unsecure child zone to indicate that the child is unsecure. A NULL
KEY record is a waste: an entire signed RRset is used to communicate KEY record is a waste: an entire signed RRset is used to communicate
effectively one bit of information--that the child is unsecure. effectively one bit of information--that the child is unsecure.
Chasing down NULL KEY RRsets complicates the resolution process in Chasing down NULL KEY RRsets complicates the resolution process in
many cases, because servers for both parent and child need to be many cases, because servers for both parent and child need to be
queried for the KEY RRset if the child server does not return it. queried for the KEY RRset if the child server does not return it.
Storing the KEY RRset only in the parent zone simplifies this and Storing the KEY RRset only in the parent zone simplifies this and
would allow the elimination of the NULL KEY RRsets entirely. For would allow the elimination of the NULL KEY RRsets entirely. For
skipping to change at page 3, line 20 skipping to change at page 3, line 20
protocols store their keys at the zone apex. Possible protocols protocols store their keys at the zone apex. Possible protocols
are IPSEC, HTTP, SMTP, SSH and others that use public key are IPSEC, HTTP, SMTP, SSH and others that use public key
cryptography. cryptography.
2. The KEY RRset may require frequent updates. 2. The KEY RRset may require frequent updates.
3. The probability of compromised or lost keys, which trigger 3. The probability of compromised or lost keys, which trigger
emergency key rollover procedures, increases. emergency key rollover procedures, increases.
4. The parent may refuse sign KEY RRsets with non-DNSSEC zone keys. 4. The parent may refuse sign KEY RRsets with non-DNSSEC zone keys.
5. The parent may not meet the child's expectations in turnaround 5. The parent may not meet the child's expectations in turnaround
time for resigning the KEY RRset. time for resigning the KEY RRset.
Given these and other reasons, there is good reason to explore Given these reasons, SIG@parent isn't any better than SIG/KEY@Child.
alternatives to using only KEY records to create a chain of trust.
Some of these problems can be reduced or eliminated by operational
rules or protocol changes. To reduce the number of keys at the zone
apex, a rule to require applications to store their KEY records at
the SRV name for that application is one possibility. Another is to
restrict the KEY record to only DNSSEC keys and create a new record
type for all non-DNSSEC keys. A third possible solution is to
prohibit the storage of non-DNSSEC keys at the zone apex. There are
other possible solutions, but they are outside the scope of this
document.
1.2 Reserved Words 1.2 Reserved Words
The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
"RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
interpreted as described in RFC2119. interpreted as described in RFC2119.
2 Specification of the Delegation key Signer 2 Specification of the Delegation key Signer
This section defines the Delegation Signer (DS) RR type and the This section defines the Delegation Signer (DS) RR type and the
skipping to change at page 4, line 37 skipping to change at page 4, line 25
amount of information stored in large delegation zones is reduced: amount of information stored in large delegation zones is reduced:
rather than the NULL KEY record at every unsecure delegation required rather than the NULL KEY record at every unsecure delegation required
by RFC 2535, only secure delegations require additional information by RFC 2535, only secure delegations require additional information
in the form of a signed DS RRset. in the form of a signed DS RRset.
The main disadvantage of this approach is that verifying a zone's KEY The main disadvantage of this approach is that verifying a zone's KEY
RRset requires two signature verification operations instead of the RRset requires two signature verification operations instead of the
one required by RFC 2535. There is no impact on the number of one required by RFC 2535. There is no impact on the number of
signatures verified for other types of RRsets. signatures verified for other types of RRsets.
Even though DS identifies two roles for KEY's, Key Signing Key (KSK)
and Zone Sigining Key (ZSK), there is no requirement that zone use
two different keys for these roles. It is expected that many small
zones will only use one key, while larger organizations will be more
likely to use multiple keys.
2.2 Protocol Change 2.2 Protocol Change
All DNS servers and resolvers that support DS MUST support the OK bit All DNS servers and resolvers that support DS MUST support the OK bit
[RFC3225] and a larger message size [RFC3226]. In order for a [RFC3225] and a larger message size [RFC3226]. In order for a
delegation to be considered secure the delegation MUST contain a DS delegation to be considered secure the delegation MUST contain a DS
RRset. If a query contains the OK bit, a server returning a referral RRset. If a query contains the OK bit, a server returning a referral
for the delegation MUST include the following RRsets in the authority for the delegation MUST include the following RRsets in the authority
section in this order: section in this order:
If DS RRset is present: If DS RRset is present:
parent NS RRset parent NS RRset
DS and SIG(DS) DS and SIG(DS)
If no DS RRset is present: If no DS RRset is present:
parent NS RRset parent NS RRset
parent NXT and SIG(NXT) parent NXT and SIG(NXT)
This increases the size of referral messages and may cause some or This increases the size of referral messages and may cause some or
all glue to be omitted. If the DS or NXT RRsets with signatures do all glue to be omitted. If the DS or NXT RRsets with signatures do
not fit in the DNS message, the TC bit MUST be set. Additional not fit in the DNS message, the TC bit MUST be set. Additional
section processing is not changed. section processing is not changed.
A DS RRset accompanying an NS RRset indicates that the child zone is A DS RRset accompanying a NS RRset indicates that the child zone is
secure. If an NS RRset exists without a DS RRset, the child zone is secure. If a NS RRset exists without a DS RRset, the child zone is
unsecure (from the parents point of view). DS RRsets MUST NOT appear unsecure (from the parents point of view). DS RRsets MUST NOT appear
at non-delegation points or at a zone's apex. at non-delegation points or at a zone's apex.
Section 2.2.1 defines special considerations related to authoritative Section 2.2.1 defines special considerations related to authoritative
servers responding to DS queries. Section 2.2.2 replaces RFC2535 servers responding to DS queries and replaces RFC2535 sections 2.3.4
sections 2.3.4 and 3.4, section 2.2.3 replaces RFC3008 section 2.7, and 3.4. Section 2.2.2 replaces RFC3008 section 2.7, and section
and section 2.2.4 updates RFC3090. 2.2.3 updates RFC3090.
2.2.2 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points 2.2.1 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points
DNS security views each zone as a unit of data completely under the DNS security views each zone as a unit of data completely under the
control of the zone owner with each entry (RRset) signed by a special control of the zone owner with each entry (RRset) signed by a special
private key held by the zone manager. But the DNS protocol views the private key held by the zone manager. But the DNS protocol views the
leaf nodes in a zone that are also the apex nodes of a child zone leaf nodes in a zone that are also the apex nodes of a child zone
(i.e., delegation points) as "really" belonging to the child zone. (i.e., delegation points) as "really" belonging to the child zone.
The corresponding domain names appear in two master files and might The corresponding domain names appear in two master files and might
have RRsets signed by both the parent and child zones' keys. A have RRsets signed by both the parent and child zones' keys. A
retrieval could get a mixture of these RRsets and SIGs, especially retrieval could get a mixture of these RRsets and SIGs, especially
since one server could be serving both the zone above and below a since one server could be serving both the zone above and below a
skipping to change at page 6, line 5 skipping to change at page 5, line 44
verifying the DS RRset from the parent, a resolver MAY trust any KEY verifying the DS RRset from the parent, a resolver MAY trust any KEY
identified in the DS RRset as a valid signer of the child's apex KEY identified in the DS RRset as a valid signer of the child's apex KEY
RRset. Resolvers configured to trust one of the keys signing the KEY RRset. Resolvers configured to trust one of the keys signing the KEY
RRset MAY now treat any data signed by the zone keys in the KEY RRset RRset MAY now treat any data signed by the zone keys in the KEY RRset
as secure. In all other cases resolvers MUST consider the zone as secure. In all other cases resolvers MUST consider the zone
unsecure. A DS RRset MUST NOT appear at a zone's apex. unsecure. A DS RRset MUST NOT appear at a zone's apex.
An authoritative server queried for type DS MUST return the DS RRset An authoritative server queried for type DS MUST return the DS RRset
in the answer section. in the answer section.
2.2.2.1 Special processing for DS queries 2.2.1.1 Special processing for DS queries
When a server is authoritative for the parent zone at a delegation When a server is authoritative for the parent zone at a delegation
point and receives a query for the DS record at that name, it will point and receives a query for the DS record at that name, it will
return the DS from the parent zone. This is true whether or not it return the DS from the parent zone. This is true whether or not it
is also authoritative for the child zone. is also authoritative for the child zone.
When the server is authoritative for the child zone at a delegation When the server is authoritative for the child zone at a delegation
point but not the parent zone, there is no natural response, since point but not the parent zone, there is no natural response, since
the child zone is not authoritative for the DS record at the zone's the child zone is not authoritative for the DS record at the zone's
apex. As these queries are only expected to originate from recursive apex. As these queries are only expected to originate from recursive
skipping to change at page 6, line 33 skipping to change at page 6, line 26
That is, it answers as if it is authoritative and the DS record does That is, it answers as if it is authoritative and the DS record does
not exist. DS-aware recursive servers will query the parent zone at not exist. DS-aware recursive servers will query the parent zone at
delegation points, so will not be affected by this. delegation points, so will not be affected by this.
A server authoritative for only the child zone at a delegation point A server authoritative for only the child zone at a delegation point
that is also a caching server MAY (if the RD bit is set in the query) that is also a caching server MAY (if the RD bit is set in the query)
perform recursion to find the DS record at the delegation point, and perform recursion to find the DS record at the delegation point, and
may return the DS record from its cache. In this case, the AA bit may return the DS record from its cache. In this case, the AA bit
MUST not be set in the response. MUST not be set in the response.
2.2.3 Signer's Name (replaces RFC3008 section 2.7) 2.2.2 Signer's Name (replaces RFC3008 section 2.7)
The signer's name field of a SIG RR MUST contain the name of the zone The signer's name field of a SIG RR MUST contain the name of the zone
to which the data and signature belong. The combination of signer's to which the data and signature belong. The combination of signer's
name, key tag, and algorithm MUST identify a zone key if the SIG is name, key tag, and algorithm MUST identify a zone key if the SIG is
to be considered material. This document defines a standard policy to be considered material. This document defines a standard policy
for DNSSEC validation; local policy may override the standard policy. for DNSSEC validation; local policy may override the standard policy.
There are no restrictions on the signer field of a SIG(0) record. There are no restrictions on the signer field of a SIG(0) record.
The combination of signer's name, key tag, and algorithm MUST The combination of signer's name, key tag, and algorithm MUST
identify a key if this SIG(0) is to be processed. identify a key if this SIG(0) is to be processed.
2.2.4 Changes to RFC3090 2.2.3 Changes to RFC3090
A number of sections of RFC3090 need to be updated to reflect the DS A number of sections of RFC3090 need to be updated to reflect the DS
record. record.
2.2.4.1 RFC3090: Updates to section 1: Introduction 2.2.3.1 RFC3090: Updates to section 1: Introduction
Most of the text is still relevant but the words ``NULL key'' are to Most of the text is still relevant but the words ``NULL key'' are to
be replaced with ``missing DS RRset''. In section 1.3 the last three be replaced with ``missing DS RRset''. In section 1.3 the last three
paragraphs discuss the confusion in sections of RFC 2535 that are paragraphs discuss the confusion in sections of RFC 2535 that are
replaced in section 2.2.1 above. Therefore, these paragraphs are now replaced in section 2.2.1 above. Therefore, these paragraphs are now
obsolete. obsolete.
2.2.4.2 RFC3090 section 2.1: Globally Secured 2.2.3.2 RFC3090 section 2.1: Globally Secured
Rule 2.1.b is replaced by the following rule: Rule 2.1.b is replaced by the following rule:
2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a 2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a
private key whose public counterpart MUST appear in a zone signing private key whose public counterpart MUST appear in a zone signing
KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to- KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to-
implement algorithm. This KEY RR MUST be identified by a DS RR in a implement algorithm. This KEY RR MUST be identified by a DS RR in a
signed DS RRset in the parent zone. signed DS RRset in the parent zone.
If a zone cannot get its parent to advertise a DS record for it, the If a zone cannot get its parent to advertise a DS record for it, the
child zone cannot be considered globally secured. The only exception child zone cannot be considered globally secured. The only exception
to this is the root zone, for which there is no parent zone. to this is the root zone, for which there is no parent zone.
2.2.4.3 RFC3090 section 3: Experimental Status. 2.2.3.3 RFC3090 section 3: Experimental Status.
The only difference between experimental status and globally secured The only difference between experimental status and globally secured
is the missing DS RRset in the parent zone. All locally secured zones is the missing DS RRset in the parent zone. All locally secured zones
are experimental. are experimental.
2.3 Comments on Protocol Changes 2.3 Comments on Protocol Changes
Over the years there have been various discussions surrounding the Over the years there have been various discussions surrounding the
DNS delegation model, declaring it to be broken because there is no DNS delegation model, declaring it to be broken because there is no
good way to assert if a delegation exists. In the RFC2535 version of good way to assert if a delegation exists. In the RFC2535 version of
skipping to change at page 8, line 11 skipping to change at page 8, line 11
for zones with DS records but will not add the NXT or DS records to for zones with DS records but will not add the NXT or DS records to
the authority section. The same is true for caching servers; in the authority section. The same is true for caching servers; in
fact, some may even refuse to pass on the DS or NXT records. fact, some may even refuse to pass on the DS or NXT records.
2.4 Wire Format of the DS record 2.4 Wire Format of the DS record
The DS (type=TDB) record contains these fields: key tag, algorithm, The DS (type=TDB) record contains these fields: key tag, algorithm,
digest type, and the digest of a public key KEY record that is digest type, and the digest of a public key KEY record that is
allowed and/or used to sign the child's apex KEY RRset. Other keys allowed and/or used to sign the child's apex KEY RRset. Other keys
MAY sign the child's apex KEY RRset. MAY sign the child's apex KEY RRset.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key tag | algorithm | Digest type | | key tag | algorithm | Digest type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SHA-1 digest | | digest (length depends on type) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (20 bytes) | | (SHA-1 digest is 20 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The key tag is calculated as specified in RFC2535. Algorithm MUST be The key tag is calculated as specified in RFC2535. Algorithm MUST be
an algorithm number assigned in the range 1..251 and the algorithm an algorithm number assigned in the range 1..251 and the algorithm
skipping to change at page 14, line 11 skipping to change at page 14, line 11
[RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC [RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC
3225, December 2001. 3225, December 2001.
[RFC3226] O. Gudmundsson, ``DNSSEC and IPv6 A6 aware server/resolver [RFC3226] O. Gudmundsson, ``DNSSEC and IPv6 A6 aware server/resolver
message size requirements'', RFC 3226, December 2001. message size requirements'', RFC 3226, December 2001.
Author Address Author Address
Olafur Gudmundsson Olafur Gudmundsson
3826 Legation Street, NW PO Box 6306
Washington, DC, 20015 Washington, DC, 20015
USA USA
<ogud@ogud.com> <ogud@ogud.com>
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
 End of changes. 

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