HEREIS "draft-vixie-dnssec-ter-00.txt"

[Paul Vixie <[e-mail]>]

   DNSEXT Working Group                                         Paul Vixie
   INTERNET-DRAFT                                                      ISC
   <draft-vixie-dnssec-ter-00.txt>                               June 2004


                      Extending DNSSEC-BIS (DNSSEC-TER)


   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.

   Abstract

      As the DNSSEC-BIS document set goes to press, we find that the design
      goals for DNSSEC have shifted somewhat in the ten years of its
      preproduction.  This memo lists some possible new directions for
      DNSSEC-TER, and also, some methods by which DNSSEC-TER could first
      coexist with, and possibly replace, DNSSEC-BIS.

   1 - Rationale and Scope

   1.1. DNSSEC-BIS, which took ten years to evolve, is widely considered to
   be a working solution for end to end DNS data authenticity.  However,
   the threat model which drove the design of DNSSEC and DNSSEC-BIS fails
   to address issues of great interest to some members of the community,
   for example, domain name confidentiality.




   Expires December 2004                                           [Page 1]

   INTERNET-DRAFT                 DNSSEC-TER                      June 2004


   1.2. Without proposing any specific new features, this memo will lay out
   an upgrade path whereby DNSSEC-TER could first coexist with, and then
   possibly replace DNSSEC-BIS, with no loss of functionality for DNSSEC-
   BIS adopters.  The method used has been called a "type code roll" or
   TCR.

   1.3. The goal of this memo is not to specify DNSSEC-TER itself, but
   rather, to describe the method by which it can be developed and
   deployed, compatibly with an existing DNSSEC-BIS installed base.

   2 - New Signalling, New Metadata

   2.1. Since DNSSEC-BIS already depends on EDNS due to message size
   increases, it is safe to depend on EDNS to carry a new DNSSEC-TER flag.
   The meaning of this flag would be, generally, "when I say I want DNSSEC
   metadata in the response to this query, I can handle, and prefer,
   DNSSEC-TER metadata."

   2.2. DNSSEC-TER might define new metadata records (for example, DS2,
   NSEC2, RRSIG2, and/or DNSKEY2), but will not redefine the meaning or
   format of existing DNSSEC-BIS metadata records due to the risk of these
   records becoming separated from the DNSSEC-TER tag that tells how to
   interpret them.

   2.3. EDNS is a hop by hop protocol, carrying meaning only between an
   initiator and a responder.  A caching forwarder who can process both
   DNSSEC-TER and DNSSEC-BIS will "tag" its security metadata using the
   "DNSSEC-TER data is wanted" status of the query which causes that
   metadata to enter the cache.  If cached data exists but was fetched
   without (or with) this tag, and a query arrives with (or without) the
   "DNSSEC-TER wanted" flag, then the new query will have to be forwarded
   upstream toward the authority servers, and the result (even if negative)
   will be cached and used separately.  This behaviour has the effect of
   promoting the "DNSSEC-TER" wanted flag from hop-by-hop to end-to-end.

   2.4. If an authority server or caching recursive server is asked for
   DNSSEC-TER metadata but only has DNSSEC-BIS metadata available, then
   DNSSEC-BIS data will be sent.  Thus, a requestor who is capable of
   handling DNSSEC-TER metadata records should ask for DNSSEC-TER first,
   and then fall back to DNSSEC-BIS if necessary.  This optimizes for the
   eventual case when the installed base of DNSSEC-BIS has completely
   upgraded to DNSSEC-TER.  An initiator is not permitted to assume, from
   the lack of a DNSSEC-TER response, that either that server or that zone
   does not in general support DNSSEC-TER.




   Expires December 2004                                           [Page 2]

   INTERNET-DRAFT                 DNSSEC-TER                      June 2004


   2.5. It is possible that DNSSEC-TER metadata could be synthesized using
   only DNSSEC-BIS metadata.  For example, an NSEC2 RR which offers the
   benefit of domain name confidentiality might use name hashes rather than
   domain names to bracket a range of name nonexistence, and it might be
   possible to compute these hashes using an existing NSEC RR.  Therefore,
   a DNSSEC-TER specification might permit caching forwarders to synthesize
   NSEC2 RRs using NSEC RRs, thus improving the number of round trips
   otherwise called for in section 2.3 above.

   2.6. A zone signer and/or authority server might choose to support both
   DNSSEC-BIS and DNSSEC-TER, or only DNSSEC-BIS, or only DNSSEC-TER.  It
   is expected that a validating recursive server, or a caching recursive
   server, will support either DNSSEC-BIS alone (as is the case today), or
   both DNSSEC-BIS and DNSSEC-TER, but never DNSSEC-TER alone.

   3 - References

   [RFC1035]  P. Mockapetris, ``Domain Names - Implementation and
              Specification,'' RFC 1035, USC/Information Sciences
              Institute, November 1987.

   [RFC2671]  P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' RFC 2671,
              IETF DNSIND, September 1998

   4 - Author's Address

                 Paul Vixie
                    Internet Systems Consortium, Inc.
                    950 Charter Street
                    Redwood City, CA 94063
                    +1.650.423.1301
                    <[e-mail]>
                    3557*VIX















   Expires December 2004                                           [Page 3]


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>