draft-ietf-dnsext-delegation-signer-13.txt   draft-ietf-dnsext-delegation-signer-14.txt 
DNSEXT Working Group Olafur Gudmundsson DNSEXT Working Group Olafur Gudmundsson
<draft-ietf-dnsext-delegation-signer-13.txt> <draft-ietf-dnsext-delegation-signer-14.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 August 28, 2003. This draft expires on December 6, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All rights reserved. Copyright (C) The Internet Society (2003). 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 3, line 30 skipping to change at page 3, line 30
Given these reasons, SIG@parent isn't any better than SIG/KEY@Child. Given these reasons, SIG@parent isn't any better than SIG/KEY@Child.
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 (type code
changes to DNS to accommodate it. TBD) and the changes to DNS to accommodate it.
2.1 Delegation Signer Record Model 2.1 Delegation Signer Record Model
This document presents a replacement for the DNSSEC KEY record chain This document presents a replacement for the DNSSEC KEY record chain
of trust [RFC2535] that uses a new RR that resides only at the of trust [RFC2535] that uses a new RR that resides only at the
parent. This record identifies the key(s) that the child uses to parent. This record identifies the key(s) that the child uses to
self-sign its own KEY RRset. self-sign its own KEY RRset.
The chain of trust is now established by verifying the parent KEY The chain of trust is now established by verifying the parent KEY
RRset, the DS RRset from the parent and the KEY RRset at the child. RRset, the DS RRset from the parent and the KEY RRset at the child.
This is cryptographically equivalent to using just KEY records. This is cryptographically equivalent to using just KEY records.
Communication between the parent and child is greatly reduced, since Communication between the parent and child is greatly reduced, since
the child only needs to notify the parent about changes in keys that the child only needs to notify the parent about changes in keys that
sign its apex KEY RRset. The parent is ignorant of all other keys in sign its apex KEY RRset. The parent is ignorant of all other keys in
the child's apex KEY RRset. Furthermore, the child maintains full the child's apex KEY RRset. Furthermore, the child maintains full
control over the apex KEY RRset and its content. The child can control over the apex KEY RRset and its content. The child can
maintain any policies regarding its KEY usage for DNSSEC and other maintain any policies regarding its KEY usage for DNSSEC with minimal
applications and protocols with minimal impact on the parent. Thus if impact on the parent. Thus if the child wants to have frequent key
the child wants to have frequent key rollover for its DNS zone keys, rollover for its DNS zone keys, the parent does not need to be aware
the parent does not need to be aware of it: the child can use one key of it. The child can use one key to sign only its apex KEY RRset and
to sign only its apex KEY RRset and other keys to sign the other a different key to sign the other RRsets in the zone.
RRsets in the zone.
This model fits well with a slow roll out of DNSSEC and the islands This model fits well with a slow roll out of DNSSEC and the islands
of security model. In this model, someone who trusts "good.example." of security model. In this model, someone who trusts "good.example."
can preconfigure a key from "good.example." as a trusted key, and can preconfigure a key from "good.example." as a trusted key, and
from then on trusts any data signed by that key or that has a chain from then on trusts any data signed by that key or that has a chain
of trust to that key. If "example." starts advertising DS records, of trust to that key. If "example." starts advertising DS records,
"good.example." does not have to change operations by suspending "good.example." does not have to change operations by suspending
self-signing. DS records can also be used to identify trusted keys self-signing. DS records can also be used to identify trusted keys
instead of KEY records. Another significant advantage is that the instead of KEY records. Another significant advantage is that the
amount of information stored in large delegation zones is reduced: amount of information stored in large delegation zones is reduced:
skipping to change at page 4, line 40 skipping to change at page 4, line 39
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 parents copy of childs 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 parents copy of childs NS RRset
parent NXT and SIG(NXT) parents zone NXT and SIG(NXT)
This increases the size of referral messages and causing some or all This increases the size of referral messages and possilbly causing
glue to be omitted. If the DS or NXT RRsets with signatures do not some or all glue to be omitted. If the DS or NXT RRsets with
fit in the DNS message, the TC bit MUST be set. Additional section signatures do not fit in the DNS message, the TC bit MUST be set.
processing is not changed. Additional section processing is not changed.
A DS RRset accompanying a NS RRset indicates that the child zone is A DS RRset accompanying a NS RRset indicates that the child zone is
secure. If a 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 and replaces RFC2535 sections 2.3.4 servers responding to DS queries and replaces RFC2535 sections 2.3.4
and 3.4. Section 2.2.2 replaces RFC3008 section 2.7, and section and 3.4. Section 2.2.2 replaces RFC3008 section 2.7, and section
2.2.3 updates RFC3090. 2.2.3 updates RFC3090.
skipping to change at page 5, line 25 skipping to change at page 5, line 24
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
delegation point [RFC 2181]. delegation point [RFC 2181].
Each DS RRset stored in the parent zone MUST be signed by, at least, Each DS RRset stored in the parent zone MUST be signed by at least
one of the parent zone's private key. The parent zone MUST NOT one of the parent zone's private key. The parent zone MUST NOT
contain a KEY RRset at any delegation point. Delegations in the contain a KEY RRset at any delegation point. Delegations in the
parent MAY contain only the following RR types: NS, DS, NXT and SIG. parent MAY contain only the following RR types: NS, DS, NXT and SIG.
The NS RRset MUST NOT be signed. The NXT RRset is the exceptional The NS RRset MUST NOT be signed. The NXT RRset is the exceptional
case: it will always appear differently and authoritatively in both case: it will always appear differently and authoritatively in both
the parent and child zones if both are secure. the parent and child zones if both are secure.
A secure zone MUST contain a self-signed KEY RRset at its apex. Upon A secure zone MUST contain a self-signed KEY RRset at its apex. Upon
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
skipping to change at page 15, line 25 skipping to change at page 15, line 25
0 is Reserved, 0 is Reserved,
1 is SHA-1. 1 is SHA-1.
Adding new reservations requires IETF standards action. Adding new reservations requires IETF standards action.
6 Acknowledgments 6 Acknowledgments
Over the last few years a number of people have contributed ideas Over the last few years a number of people have contributed ideas
that are captured in this document. The core idea of using one key to that are captured in this document. The core idea of using one key to
sign only the KEY RRset comes from discussions with Bill Manning and sign only the KEY RRset comes from discussions with Bill Manning and
Perry Metzger on how to put in a single root key in all resolvers. Perry Metzger on how to put in a single root key in all resolvers.
Alexis Yushin, Brian Wellington, Paul Vixie, Jakob Schlyter, Scott Alexis Yushin, Brian Wellington, Sam Weiler, Paul Vixie, Jakob
Rose, Edward Lewis, Lars-Johan Liman, Matt Larson, Mark Kosters, Dan Schlyter, Scott Rose, Edward Lewis, Lars-Johan Liman, Matt Larson,
Massey, Olaf Kolman, Phillip Hallam-Baker, Miek Gieben, Havard Mark Kosters, Dan Massey, Olaf Kolman, Phillip Hallam-Baker, Miek
Eidnes, Donald Eastlake 3rd., Randy Bush, David Blacka, Steve Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David
Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark Andrews, Harald Blacka, Steve Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark
Alvestrand, and others have provided useful comments. Andrews, Harald Alvestrand, and others have provided useful comments.
Normative References: Normative References:
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and [RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification'', STD 13, RFC 1035, November 1987. Specification'', STD 13, RFC 1035, November 1987.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC [RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC
2535, March 1999. 2535, March 1999.
[RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing [RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing
Authority'', RFC 3008, November 2000. Authority'', RFC 3008, November 2000.
[RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone [RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone
Status'', RFC 3090, March 2001. Status'', RFC 3090, March 2001.
[RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC
3225, December 2001.
[RFC3445] D. Massey, S. Rose ``Limiting the scope of the KEY Resource [RFC3445] D. Massey, S. Rose ``Limiting the scope of the KEY Resource
Record (RR)``, RFC 3445, December 2002. Record (RR)``, RFC 3445, December 2002.
Informational References Informational References
[RFC2181] R. Elz, R. Bush, ``Clarifications to the DNS Specification'', [RFC2181] R. Elz, R. Bush, ``Clarifications to the DNS Specification'',
RFC 2181, July 1997. RFC 2181, July 1997.
[RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC
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
3821 Village Park Drive 3821 Village Park Drive
Chevy Chase, MD, 20815 Chevy Chase, MD, 20815
USA USA
 End of changes. 

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