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

bind-3.2.

   delegations are locally secure. This is bad, but the DNSEXT Working
   Group has determined that rather than dealing with both
   RFC2535-secured zones and DS-secured zones, a rapid adoption of DS is
   preferable.  Thus the only option for early adopters is to upgrade to
   DS as soon as possible.

2.6.1 Backwards compatibility with RFC2535 and RFC1035

   This section documents how a resolver determines the type of
   delegation.
   RFC1035 delegation (in parent) has:

   RFC1035           NS

   RFC2535 adds the following two cases:



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


   Secure RFC2535:   NS + NXT + SIG(NXT)
                     NXT bit map contains: NS SIG NXT
   Unsecure RFC2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT)
                     NXT bit map contains: NS SIG KEY NXT
                     KEY must be a NULL key.

   DNSSEC with DS has the following two states:

   Secure DS:        NS + DS + SIG(DS)
                     NXT bit map contains: NS SIG NXT DS
   Unsecure DS:      NS + NXT + SIG(NXT)
                     NXT bit map contains: NS SIG NXT

   It is difficult for a resolver to determine if a delegation is secure
   RFC 2535 or unsecure DS. This could be overcome by adding a flag to
   the NXT bit map, but only upgraded resolvers would understand this
   flag, anyway. Having both parent and child signatures for a KEY RRset
   might allow old resolvers to accept a zone as secure, but the cost of
   doing this for a long time is much higher than just prohibiting RFC
   2535-style signatures at child zone apexes and forcing rapid
   deployment of DS-enabled servers and resolvers.

   RFC 2535 and DS can in theory be deployed in parallel, but this would
   require resolvers to deal with RFC 2535 configurations forever.  This
   document obsoletes the NULL KEY in parent zones, which is a difficult
   enough change that a flag day is required.

2.7 KEY and corresponding DS record example

   This is an example of a KEY record and the corresponding DS record.

   dskey.example. KEY  256 3 1 (
                  AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj
                  4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt
                  ) ; key id = 28668
             DS   28668 1  1  49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
















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


3 Resolver

3.1 DS Example

   To create a chain of trust, a resolver goes from trusted KEY to DS to
   KEY.

   Assume the key for domain "example." is trusted.  Zone "example."
   contains at least the following records:
   example.          SOA     <soa stuff>
   example.          NS       ns.example.
   example.          KEY     <stuff>
   example.          NXT      NS SOA KEY SIG NXT secure.example.
   example.          SIG(SOA)
   example.          SIG(NS)
   example.          SIG(NXT)
   example.          SIG(KEY)
   secure.example.   NS      ns1.secure.example.
   secure.example.   DS      tag=12345 alg=3 digest_type=1 <foofoo>
   secure.example.   NXT     NS SIG NXT DS unsecure.example.
   secure.example.   SIG(NXT)
   secure.example.   SIG(DS)
   unsecure.example  NS      ns1.unsecure.example.
   unsecure.example. NXT     NS SIG NXT example.
   unsecure.example. SIG(NXT)

   In zone "secure.example." following records exist:
   secure.example.   SOA      <soa stuff>
   secure.example.   NS       ns1.secure.example.
   secure.example.   KEY      <tag=12345 alg=3>
   secure.example.   KEY      <tag=54321 alg=5>
   secure.example.   NXT      <nxt stuff>
   secure.example.   SIG(KEY) <key-tag=12345 alg=3>
   secure.example.   SIG(SOA) <key-tag=54321 alg=5>
   secure.example.   SIG(NS)  <key-tag=54321 alg=5>
   secure.example.   SIG(NXT) <key-tag=54321 alg=5>

   In this example the private key for "example." signs the DS record
   for "secure.example.", making that a secure delegation. The DS record
   states which key is expected to sign the KEY RRset at
   "secure.example.".  Here "secure.example." signs its KEY RRset with
   the KEY identified in the DS RRset, thus the KEY RRset is validated
   and trusted.

   This example has only one DS record for the child, but parents MUST
   allow multiple DS records to facilitate key rollover and multiple KEY
   algorithms.





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


   The resolver determines the security status of "unsecure.example." by
   examining the parent zone's NXT record for this name.  The absence of
   the DS bit indicates an unsecure delegation. Note the NXT record
   SHOULD only be examined after verifying the corresponding signature.

3.1 Resolver Cost Estimates for DS Records

   From a RFC2535 resolver point of view, for each delegation followed
   to chase down an answer, one KEY RRset has to be verified.
   Additional RRsets might also need to be verified based on local
   policy (e.g., the contents of the NS RRset). Once the resolver gets
   to the appropriate delegation, validating the answer might require
   verifying one or more signatures.  A simple A record lookup requires
   at least N delegations to be verified and one RRset. For a DS-enabled
   resolver, the cost is 2N+1.  For an MX record, where the target of
   the MX record is in the same zone as the MX record, the costs are N+2
   and 2N+2, for RFC 2535 and DS, respectively. In the case of negatives
   answer the same ratios hold true.

   The resolver may require an extra query to get the DS record and this
   may add to the overall cost of the query, but this is never worse
   than chasing down NULL KEY records from the parent in RFC2535 DNSSEC.

   DS adds processing overhead on resolvers and increases the size of
   delegation answers, but much less than storing signatures in the
   parent zone.

4 Security Considerations:

   This document proposes a change to the validation chain of KEY
   records in DNSSEC. The change is not believed to reduce security in
   the overall system. In RFC2535 DNSSEC, the child zone has to
   communicate keys to its parent and prudent parents will require some
   authentication with that transaction. The modified protocol will
   require the same authentication, but allows the child to exert more
   local control over its own KEY RRset.

   There is a remote possibility that an attacker could generate a valid
   KEY that matches all the DS fields, of a specific DS set, and thus
   forge data from the child. This possibility is considered
   impractical, as on average more than
       2 ^ (160 - <Number of keys in DS set>)
   keys would have to be generated before a match would be found.

   An attacker that wants to match any DS record will have to generate
   on average at least 2^80 keys.

   The DS record represents a change to the DNSSEC protocol and there is
   an installed base of implementations, as well as textbooks on how to



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


   set up secure delegations. Implementations that do not understand the
   DS record will not be able to follow the KEY to DS to KEY chain and
   will consider all zones secured that way as unsecure.

5 IANA Considerations:

   IANA needs to allocate an RR type code for DS from the standard RR
   type space (type 43 requested).

   IANA needs to open a new registry for the DS RR type for digest
   algorithms. Defined types are:
       0 is Reserved,
       1 is SHA-1.
   Adding new reservations requires IETF standards action.

6 Acknowledgments

   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
   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.
   Alexis Yushin, Brian Wellington, Sam Weiler, Paul Vixie, Jakob
   Schlyter, Scott Rose, Edward Lewis, Lars-Johan Liman, Matt Larson,
   Mark Kosters, Dan Massey, Olaf Kolman, Phillip Hallam-Baker, Miek
   Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David
   Blacka, Steve Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark
   Andrews, Harald Alvestrand, and others have provided useful comments.

Normative References:

[RFC1035]  P. Mockapetris, ``Domain Names - Implementation and
           Specification'', STD 13, RFC 1035, November 1987.

[RFC2535]  D. Eastlake, ``Domain Name System Security Extensions'', RFC
           2535, March 1999.

[RFC3008]  B. Wellington, ``Domain Name System Security (DNSSEC) Signing
           Authority'', RFC 3008, November 2000.

[RFC3090]  E. Lewis `` DNS Security Extension Clarification on Zone
           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
           Record (RR)``, RFC 3445, December 2002.





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


Informational References

[RFC2181]  R. Elz, R. Bush, ``Clarifications to the DNS Specification'',
           RFC 2181, July 1997.

[RFC3226]  O. Gudmundsson, ``DNSSEC and IPv6 A6 aware server/resolver
           message size requirements'', RFC 3226, December 2001.

Author Address

      Olafur Gudmundsson
      3821 Village Park Drive
      Chevy Chase, MD,  20815
      USA
      <[e-mail]>

Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."









Gudmundsson               Expires December 2003                [Page 16]