draft-ietf-dnsext-delegation-signer-14.txt

bind-3.2.

  DNSEXT Working Group                                Olafur Gudmundsson
  INTERNET-DRAFT                                                May 2003
  <draft-ietf-dnsext-delegation-signer-14.txt>

  Updates: RFC 1035, RFC 2535, RFC 3008, RFC 3090.


                   Delegation Signer Resource Record


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   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/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   Comments should be sent to the authors or the DNSEXT WG mailing list
   [e-mail]

   This draft expires on December 6, 2003.

   Copyright Notice

   Copyright (C) The Internet Society (2003).  All rights reserved.



Abstract

   The delegation signer (DS) resource record is inserted at a zone cut
   (i.e., a delegation point) to indicate that the delegated zone is
   digitally signed and that the delegated zone recognizes the indicated
   key as a valid zone key for the delegated zone. The DS RR is a
   modification to the DNS Security Extensions definition, motivated by



Gudmundsson               Expires December 2003                 [Page 1]

INTERNET-DRAFT          Delegation Signer Record           February 2003


   operational considerations. The intent is to use this resource record
   as an explicit statement about the delegation, rather than relying on
   inference.

   This document defines the DS RR, gives examples of how it is used and
   the implications of this record on resolvers. This change is not
   backwards compatible with RFC 2535.
   This document updates RFC1035, RFC2535, RFC3008 and RFC3090.


1 Introduction

   Familiarity with the DNS system [RFC1035], DNS security extensions
   [RFC2535] and DNSSEC terminology [RFC3090] is important.

   Experience shows that when the same data can reside in two
   administratively different DNS zones, the data frequently gets out of
   sync. The presence of an NS RRset in a zone anywhere other than at
   the apex indicates a zone cut or delegation.  The RDATA of the NS
   RRset specifies the authoritative servers for the delegated or
   "child" zone. Based on actual measurements, 10-30% of all delegations
   on the Internet have differing NS RRsets at parent and child. There
   are a number of reasons for this, including a lack of communication
   between parent and child and bogus name servers being listed to meet
   registry requirements.

   DNSSEC [RFC2535,RFC3008,RFC3090] specifies that a child zone needs to
   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
   should reside, whether at the child [RFC2535] or at the parent. If
   the KEY RRset resides at the child, maintaining the signed KEY RRset
   in the child requires frequent two-way communication between the two
   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
   RRset at the parent was thought to simplify the communication.

   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
   KEY record is a waste: an entire signed RRset is used to communicate
   effectively one bit of information--that the child is unsecure.
   Chasing down NULL KEY RRsets complicates the resolution process in
   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.
   Storing the KEY RRset only in the parent zone simplifies this and
   would allow the elimination of the NULL KEY RRsets entirely. For
   large delegation zones the cost of NULL keys is a significant barrier
   to deployment.





Gudmundsson               Expires December 2003                 [Page 2]

INTERNET-DRAFT          Delegation Signer Record           February 2003


   Another complication of the DNSSEC key model is that the KEY record
   can be used to store public keys for other protocols in addition to
   DNSSEC keys.  There are number of potential problems with this,
   including:
   1. The KEY RRset can become quite large if many applications and
      protocols store their keys at the zone apex. Possible protocols
      are IPSEC, HTTP, SMTP, SSH and others that use public key
      cryptography.
   2. The KEY RRset may require frequent updates.
   3. The probability of compromised or lost keys, which trigger
      emergency key rollover procedures, increases.
   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
      time for resigning the KEY RRset.

   Given these reasons, SIG@parent isn't any better than SIG/KEY@Child.


1.2 Reserved Words

   The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
   interpreted as described in RFC2119.

2 Specification of the Delegation key Signer

   This section defines the Delegation Signer (DS) RR type (type code
   TBD) and the changes to DNS to accommodate it.

2.1 Delegation Signer Record Model

   This document presents a replacement for the DNSSEC KEY record chain
   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
   self-sign its own KEY RRset.

   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.
   This is cryptographically equivalent to using just KEY records.

   Communication between the parent and child is greatly reduced, since
   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
   the child's apex KEY RRset. Furthermore, the child maintains full
   control over the apex KEY RRset and its content.  The child can
   maintain any policies regarding its KEY usage for DNSSEC with minimal
   impact on the parent. Thus if the child wants to have frequent key
   rollover for its DNS zone keys, the parent does not need to be aware
   of it. The child can use one key to sign only its apex KEY RRset and



Gudmundsson               Expires December 2003                 [Page 3]

INTERNET-DRAFT          Delegation Signer Record           February 2003


   a different key to sign the other RRsets in the zone.

   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."
   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
   of trust to that key.  If "example." starts advertising DS records,
   "good.example." does not have to change operations by suspending
   self-signing. DS records can also be used to identify trusted keys
   instead of KEY records.  Another significant advantage is that the
   amount of information stored in large delegation zones is reduced:
   rather than the NULL KEY record at every unsecure delegation required
   by RFC 2535, only secure delegations require additional information
   in the form of a signed DS RRset.

   The main disadvantage of this approach is that verifying a zone's KEY
   RRset requires two signature verification operations instead of the
   one required by RFC 2535.  There is no impact on the number of
   signatures verified for other types of RRsets.

   Even though DS identifies two roles for KEY's, Key Signing Key (KSK)
   and Zone Signing 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

   All DNS servers and resolvers that support DS MUST support the OK bit
   [RFC3225] and a larger message size [RFC3226].  In order for a
   delegation to be considered secure the delegation MUST contain a DS
   RRset.  If a query contains the OK bit, a server returning a referral
   for the delegation MUST include the following RRsets in the authority
   section in this order:
   If DS RRset is present:
        parents copy of childs NS RRset
        DS and SIG(DS)
   If no DS RRset is present:
        parents copy of childs NS RRset
        parents zone NXT and SIG(NXT)

   This increases the size of referral messages and possilbly causing
   some or 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 section processing is not changed.

   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
   unsecure (from the parents point of view).  DS RRsets MUST NOT appear



Gudmundsson               Expires December 2003                 [Page 4]

INTERNET-DRAFT          Delegation Signer Record           February 2003


   at non-delegation points or at a zone's apex.

   Section 2.2.1 defines special considerations related to authoritative
   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
   2.2.3 updates RFC3090.


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
   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
   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.
   The corresponding domain names appear in two master files and might
   have RRsets signed by both the parent and child zones' keys. A
   retrieval could get a mixture of these RRsets and SIGs, especially
   since one server could be serving both the zone above and below a
   delegation point [RFC 2181].

   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
   contain a KEY RRset at any delegation point. Delegations in the
   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
   case: it will always appear differently and authoritatively in both
   the parent and child zones if both are secure.

   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
   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 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
   unsecure. A DS RRset MUST NOT appear at a zone's apex.

   An authoritative server queried for type DS MUST return the DS RRset
   in the answer section.


2.2.1.1  Special processing for DS queries

   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
   return the DS from the parent zone.  This is true whether or not it
   is also authoritative for the child zone.





Gudmundsson               Expires December 2003                 [Page 5]

INTERNET-DRAFT          Delegation Signer Record           February 2003


   When the server is authoritative for the child zone at a delegation
   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
   apex.  As these queries are only expected to originate from recursive
   servers which are not DS-aware, the authoritative server MUST answer
   with:
        RCODE:             NOERROR
        AA bit:            set
        Answer Section:    Empty
        Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]

   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
   delegation points, so will not be affected by this.