draft-ietf-dnsext-dnssec-opt-in-05.txt

bind-3.2.

Arends, et al.          Expires August 28, 2003                 [Page 9]

Internet-Draft               DNSSEC Opt-In                 February 2003


4. Benefits

   Using Opt-In allows administrators of large and/or changing
   delegation-centric zones to minimize the overhead involved in
   maintaining the security of the zone.

   Opt-In accomplishes this by eliminating the need for both "no-key"
   KEY (in [2]) and NXT records for insecure delegations.  This, in a
   zone with a large number of delegations to unsigned subzones, can
   lead to substantial space savings (both in memory and on disk).
   Additionally, Opt-In allows for the addition or removal of insecure
   delegations without modifying the NXT record chain.  Zones that are
   frequently updating insecure delegations (e.g., TLDs) can avoid the
   substantial overhead of modifying and resigning the affected NXT
   records.




































Arends, et al.          Expires August 28, 2003                [Page 10]

Internet-Draft               DNSSEC Opt-In                 February 2003


5. Example

   Consider the zone EXAMPLE, shown below.  This is a zone where all of
   the NXT records are tagged as Opt-In.

   Example A: Fully DS/Opt-In Zone.

         EXAMPLE.               SOA   ...
         EXAMPLE.               SIG   SOA ...
         EXAMPLE.               NS    FIRST-SECURE.EXAMPLE.
         EXAMPLE.               SIG   NS ...
         EXAMPLE.               KEY   ...
         EXAMPLE.               SIG   KEY ...
         EXAMPLE.               NXT   FIRST-SECURE.EXAMPLE. SOA NS SIG KEY
         EXAMPLE.               SIG   NXT ...

         FIRST-SECURE.EXAMPLE.  A     ...
         FIRST-SECURE.EXAMPLE.  SIG   A ...
         FIRST-SECURE.EXAMPLE.  NXT   NOT-SECURE-2.EXAMPLE. A SIG
         FIRST-SECURE.EXAMPLE.  SIG   NXT ...

         NOT-SECURE.EXAMPLE.    NS    NS.NOT-SECURE.EXAMPLE.
         NS.NOT-SECURE.EXAMPLE. A     ...

         NOT-SECURE-2.EXAMPLE.  NS    NS.NOT-SECURE.EXAMPLE.
         NOT-SECURE-2.EXAMPLE   NXT   SECOND-SECURE.EXAMPLE NS SIG
         NOT-SECURE-2.EXAMPLE   SIG   NXT ...

         SECOND-SECURE.EXAMPLE. NS    NS.ELSEWHERE.
         SECOND-SECURE.EXAMPLE. DS    ...
         SECOND-SECURE.EXAMPLE. SIG   DS ...
         SECOND-SECURE.EXAMPLE. NXT   EXAMPLE. NS SIG KEY
         SECOND-SECURE.EXAMPLE. SIG   NXT ...

         UNSIGNED.EXAMPLE.      NS    NS.UNSIGNED.EXAMPLE.
         NS.UNSIGNED.EXAMPLE.   A     ...


   In this example, a query for a signed RRset (e.g.,
   "FIRST-SECURE.EXAMPLE A"), or a secure delegation
   ("WWW.SECOND-SECURE.EXAMPLE A") will result in a standard RFC 2535
   response.

   A query for a nonexistent RRset will result in a response that
   differs from RFC 2535 by: the NXT record will be tagged as Opt-In,
   there may be no NXT record proving the non-existence of a matching
   wildcard record, and the AD bit will not be set.




Arends, et al.          Expires August 28, 2003                [Page 11]

Internet-Draft               DNSSEC Opt-In                 February 2003


   A query for an insecure delegation RRset (or a referral) will return
   both the answer (in the Authority section) and the corresponding
   Opt-In NXT record to prove that it is not secure.

   Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A


         RCODE=NOERROR, AD=0

         Answer Section:

         Authority Section:
         UNSIGNED.EXAMPLE.      NS    NS.UNSIGNED.EXAMPLE
         SECOND-SECURE.EXAMPLE. NXT   EXAMPLE. NS SIG DS
         SECOND-SECURE.EXAMPLE. SIG   NXT ...

         Additional Section:
         NS.UNSIGNED.EXAMPLE.   A     ...

   In the Example A.1 zone, the EXAMPLE. node MAY use either style of
   NXT record, because there are no insecure delegations that occur
   between it and the next node, FIRST-SECURE.EXAMPLE. In other words,
   Example A would still be a valid zone if the NXT record for EXAMPLE.
   was changed to the following RR:

         EXAMPLE.               NXT   FIRST-SECURE.EXAMPLE. SOA NS SIG KEY NXT

   However, the other NXT records (FIRST-SECURE.EXAMPLE. and
   SECOND-SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are
   insecure delegations in the range they define. (NOT-SECURE.EXAMPLE.
   and UNSIGNED.EXAMPLE., respectively).

   NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is
   part of the NXT chain and also covered by an Opt-In tagged NXT
   record.  Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be
   removed from the zone without modifying and resigning the prior NXT
   record.  Delegations with names that fall between
   NOT-SECURE-2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or
   removed without resigning any NXT records.












Arends, et al.          Expires August 28, 2003                [Page 12]

Internet-Draft               DNSSEC Opt-In                 February 2003


6. Transition Issues

   Opt-In is not backwards compatible with RFC 2535.  RFC 2535 compliant
   DNSSEC implementations will not recognize Opt-In tagged NXT records
   as different from RFC 2535 NXT records. Because of this, RFC 2535
   implementations will reject all Opt-In insecure delegations within a
   zone as invalid.












































Arends, et al.          Expires August 28, 2003                [Page 13]

Internet-Draft               DNSSEC Opt-In                 February 2003


7. Security Considerations

   Opt-In allows for unsigned names, in the form of delegations to
   unsigned subzones, to exist within an otherwise signed zone. All
   unsigned names are, by definition, insecure, and their validity or
   existence cannot by cryptographically proven.

   In general:

   o  Records with unsigned names (whether existing or not) suffer from
      the same vulnerabilities as records in an unsigned zone.  These
      vulnerabilites are described in more detail in [10] (note in
      particular sections 2.3, "Name Games" and 2.6, "Authenticated
      Denial").

   o  Records with signed names have the same security whether or not
      Opt-In is used.

   Note that with or without Opt-In, an insecure delegation may have its
   contents undetectably altered by an attacker.  Because of this, the
   primary difference in security that Opt-In introduces is the loss of
   the ability to prove the existence or nonexistence of an insecure
   delegation within the span of an Opt-In NXT record.

   In particular, this means that a malicious entity may be able to
   insert or delete records with unsigned names.  These records are
   normally NS records, but this also includes signed wildcard
   expansions (while the wildcard record itself is signed, its expanded
   name is an unsigned name).

   For example, if a resolver received the following response from the
   example zone above:



















Arends, et al.          Expires August 28, 2003                [Page 14]

Internet-Draft               DNSSEC Opt-In                 February 2003


   Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A

         RCODE=NOERROR

         Answer Section:

         Authority Section:
         DOES-NOT-EXIST.EXAMPLE. NS    NS.FORGED.
         EXAMPLE.                NXT   FIRST-SECURE.EXAMPLE. SOA NS SIG KEY
         EXAMPLE.                SIG   NXT ...

         Additional Section:


   The resolver would have no choice but to believe that the referral to
   NS.FORGED. is valid.  If a wildcard existed that would have been
   expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
   have undetectably removed it and replaced it with the forged
   delegation.

   Note that being able to add a delegation is functionally equivalent
   to being able to add any record type: an attacker merely has to forge
   a delegation to nameserver under his/her control and place whatever
   records needed at the subzone apex.

   While in particular cases, this issue may not present a significant
   security problem, in general it should not be lightly dismissed.
   Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
   In particular, zone signing tools SHOULD NOT default to Opt-In, and
   MAY choose to not support Opt-In at all.





















Arends, et al.          Expires August 28, 2003                [Page 15]

Internet-Draft               DNSSEC Opt-In                 February 2003


8. IANA Considerations

   None.
















































Arends, et al.          Expires August 28, 2003                [Page 16]

Internet-Draft               DNSSEC Opt-In                 February 2003


9. Acknowledgments

   The contributions, suggestions and remarks of the following persons
   (in alphabetic order) to this draft are acknowledged:

      Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf
      Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning,
      Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian
      Wellington.










































Arends, et al.          Expires August 28, 2003                [Page 17]

Internet-Draft               DNSSEC Opt-In                 February 2003


Normative References

   [1]  Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, November 1987.

   [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
        2535, March 1999.

   [3]  Gudmundsson, O., "Delegation Signer Resource Record",
        draft-ietf-dnsext-delegation-signer-12 (work in progress),
        December 2002.

   [4]  Gudmundsson, O. and B. Wellington, "Redefinition of DNS AD bit",
        draft-ietf-dnsext-ad-is-secure-06 (work in progress), June 2002.