Skip to main content

DBOUND: DNS Administrative Boundaries Problem Statement
draft-sullivan-dbound-problem-statement-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Andrew Sullivan , Jeff Hodges , John R. Levine , Casey Deccio
Last updated 2015-01-07
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-sullivan-dbound-problem-statement-00
IETF                                                         A. Sullivan
Internet-Draft                                                 Dyn, Inc.
Intended status: Standards Track                               J. Hodges
Expires: July 11, 2015                                            PayPal
                                                               J. Levine
                                                    Taughannock Networks
                                                               C. Deccio
                                                                Verisign
                                                         January 7, 2015

        DBOUND: DNS Administrative Boundaries Problem Statement
               draft-sullivan-dbound-problem-statement-00

Abstract

   Some Internet client entities on the Internet make inferences about
   the administrative relationships among services on the Internet based
   on the domain names at which they are offered.  At present, it is not
   possible to ascertain organizational administrative boundaries in the
   DNS, therefore such inferences can be erroneous in various ways.
   Mitigation strategies deployed so far will not scale.  The solution
   offered in this memo is to provide a means to make explicit
   assertions regarding the administrative relationships between domain
   names.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on July 11, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Sullivan, et al.          Expires July 11, 2015                 [Page 1]
Internet-Draft          Asserting DNS Boundaries            January 2015

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Prerequisites, Terminology, and Organization of this Memo . .   2
   2.  Introduction and Motivation . . . . . . . . . . . . . . . . .   2
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   6
   Appendix A.  Discussion Venue . . . . . . . . . . . . . . . . . .   8
   Appendix B.  Change History . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Prerequisites, Terminology, and Organization of this Memo

   The reader is assumed to be familiar with the DNS ([RFC1034]
   [RFC1035]) and the omain Name System Security Extensions (DNSSEC)
   ([RFC4033] [RFC4034] [RFC4035] [RFC5155]).

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   To begin, Section 2 describes introduces the problem space and
   motivations for this work.  Then, Section 3 discusses the cases where
   a there are needs for discerning administrative boundaries in the DNS
   domain name space.  [[TODO:Flesh out]]

2.  Introduction and Motivation

   Many Internet resources and services, especially at the application
   layer, are identified primarily by DNS domain names [RFC1034].  As a
   result, domain names have become fundamental elements in building
   security policies and also in affecting user agent behaviour.  For
   example, domain names are used for defining the scope of HTTP state
   management "cookies" [RFC6265].

Sullivan, et al.          Expires July 11, 2015                 [Page 2]
Internet-Draft          Asserting DNS Boundaries            January 2015

   Another example is a user interface convention that purports to
   display an "actual domain name" differently from other parts of a
   fully-qualified domain name, in an effort to decrease the success of
   phishing attacks.  In this strategy, for instance, a domain name like
   "www.bank.example.com.attackersite.tld" is formatted to highlight
   that the actual domain name ends in "attackersite.tld", in the hope
   of reducing user's potential impression of visiting
   "www.bank.example.com".

   Issuers of X.509 certificates make judgements about administrative
   boundaries around domains when issuing the certificates.  For some
   discussion of the relationship between domain names and X.509
   certificates, see [RFC6125].

   The simplest policy, and the one most likely to work, is to treat
   each different domain name distinctly.  Under this approach,
   foo.example.org, bar.example.org, and baz.example.org are all just
   different domains.  Unfortunately, this approach is too naive to be
   useful.  Often, the real policy control is the same in several names
   (in this example, example.org and its children).  Therefore, clients
   have attempted to make more sophisticated policies around some idea
   of such shared control.  We call such an area of shared control a
   "policy realm", and the control held by the administrator the "policy
   authority".

   Historically, policies were sometimes based on the DNS tree.  Early
   policies made a firm distinction between top-level domains and
   everything else; but this was also too naive, and later attempts were
   based on inferences from the domain names themselves.  That did not
   work well, because there is no way in the DNS to discover the
   boundaries of policy control around domain names.

   Some have attempted to use the boundary of zone cuts (i.e. the
   location of the zone's apex, which is at the SOA record; see
   [RFC1034] and [RFC1035]).  That boundary is neither necessary nor
   sufficient for these purposes: it is possible for a large site to
   have many, administratively distinct subdomain-named sites without
   inserting an SOA record, and it is also possible that an
   administrative entity (like a company) might divide its domain up
   into different zones for administrative reasons unrelated to the
   names in that domain.  It was also, prior to the advent of DNSSEC,
   difficult to find zone cuts.  Regardless, the location of a zone cut
   is an administrative matter to do with the operation of the DNS
   itself, and not useful for determining relationships among services
   offered at names in the DNS.

   These different issues often appear to be different kinds of
   problems.  The issue of whether two names may set cookies for one

Sullivan, et al.          Expires July 11, 2015                 [Page 3]
Internet-Draft          Asserting DNS Boundaries            January 2015

   another appears to be a different matter from whether two names get
   the same highlighting in a browser's address bar, or whether a
   particular name "owns" all the names underneath it.  But the problems
   all boil down to the same fundamental problem, which is that of
   determining whether two different names in the DNS are under the
   control of the same entity and ought to be treated as having an
   important administrative relationship to one another.

   What appears to be needed is a mechanism to determine policy
   boundaries in the DNS.  That is, given two domain names, one needs to
   be able to answer whether the first and the second are under the same
   administrative control and same administrative policies.  We may call
   this state of affairs "being within the same policy realm".  We may
   suppose that, if this information were to be available, it would be
   possible to make useful decisions based on the information.

   A particularly important distinction for security purposes is the one
   between names that are mostly used to contain other domains, as
   compared to those that are mostly used to operate services.  The
   former are often "delegation-centric" domains, delegating parts of
   their name space to others, and are frequently called "public suffix"
   domains or "effective TLDs".  The term "public suffix" comes from a
   site, [publicsuffix.org], that publishes a list of domains -- which
   is also known as the "effective TLD (eTLD) list", and henceforth in
   this specification as the "public suffix list" -- that are used to
   contain other domains.  Not all, but most, delegation-centric domains
   are public suffix domains; and not all public suffix domains need to
   do DNS delegation, although most of them do.  The reason for the
   public suffix list is to make the distinction between names that must
   never be treated as being in the same policy realm as another, and
   those that might be so treated.  For instance, if "com" is on the
   public suffix list, that means that "example.com" lies in a policy
   realm distinct from that of com.

   Unfortunately, the public suffix list has several inherent
   limitations.  To begin with, it is a list that is separately
   maintained from the list of DNS delegations.  As a result, the data
   in the public suffix list can diverge from the actual use of the DNS.
   Second, because its semantics are not the same as those of the DNS,
   it does not capture unusual features of the DNS that are a
   consequence of its structure (see [RFC1034] for background on that
   structure).  Third, as the size of the root zone grows, keeping the
   list both accurate and synchronized with the expanding services will
   become difficult and unreliable.  Perhaps most importantly, it puts
   the power of assertion about the operational policies of a domain
   outside the control of the operators of that domain, and in the
   control of a third party possibly unrelated to those operators.

Sullivan, et al.          Expires July 11, 2015                 [Page 4]
Internet-Draft          Asserting DNS Boundaries            January 2015

   There have been suggestions for improvements of the public suffix
   list, most notably in [I-D.pettersen-subtld-structure].  It is
   unclear the extent to which those improvements would help, because
   they represent improvements on the fundamental mechanism of keeping
   metadata about the DNS tree apart from the DNS tree itself.

3.  Use Cases

   In the most general sense, this memo presents a mechanism that can be
   used either as a replacement of the public suffix list
   [publicsuffix.org], or else as a way to build and maintain such a
   list.  The mechanism outlined here is explicitly restricted to names
   having ancestor-descendant or sibling relationships, but only as a
   practical matter; nothing about the mechanism makes that restriction
   a requirement.

   HTTP state management cookies  The mechanism can be used to determine
      the scope for data sharing of HTTP state management cookies
      [RFC6265].  Using this mechansim, it is possible to determine
      whether a service at one name may be permitted to set a cookie for
      a service at a different name.  (Other protocols use cookies, too,
      and those approaches could benefit similarly.)

   User interface indicators  User interfaces sometimes attempt to
      indicate the "real" domain name in a given domain name.  A common
      use is to highlight the portion of the domain name believed to be
      the "real" name -- usually the rightmost three or four labels in a
      domain name string.

   Setting the document.domain property  The DOM same-origin policy
      might be helped by being able to identify a common policy realm.

   Email authentication mechanisms  Mail authentication mechanisms such
      as DMARC [I-D.kucherawy-dmarc-base] need to be able to find policy
      documents for a given domain name given a subdomain.

   SSL and TLS certificates  Certificate authorities need to be able to
      discover delegation-centric domains in order to avoid issuance of
      certificates at or above those domains.

   HSTS and Public Key Pinning with           includeSubDomains flag set

   Linking domains together for reporting             purposes

   DMARC science fiction use case  DMARC's current use of the PSL is to
      determine the 'Organizational Domain'.. for use when discovering
      DMARC policy records.  PSL works well enough for production

Sullivan, et al.          Expires July 11, 2015                 [Page 5]
Internet-Draft          Asserting DNS Boundaries            January 2015

      environments in today's world.  However, after hearing about
      cross-domain requirements of cookies and cross-domain security use
      cases in the browser, it strikes me that any functionality (policy
      authority?) that allows domains to be linked would be incredibly
      useful in the DMARC world, too.  DMARC?s requirement for
      Identifier Alignment between SPF-authenticated domain, DKIM
      d=domain, and a message?s From: domain could be relaxed to include
      domains that were somehow associated via a policy authority.  This
      capability would be *very* nice to have at hand.

4.  Security Considerations

   This mechanism enables publication of assertions about administrative
   relationships of different DNS-named systems on the Internet.  If
   such assertions are accepted without checking that both sides agree
   to the assertion, it would be possible for one site to become an
   illegitimate source for data to be consumed in some other site.  In
   general, assertions about another name should never be accepted
   without querying the other name for agreement.

   Undertaking any of the inferences suggested in this draft without the
   use of the DNS Security Extensions exposes the user to the
   possibility of forged DNS responses.

5.  IANA Considerations

   IANA will be requested to register the SOPA RRTYPE if this proceeds.

6.  Acknowledgements

   TODO: update this

   The authors thank Adam Barth, Dave Crocker, Brian Dickson, Phillip
   Hallam-Baker, John Klensin, Murray Kucherawy, John Levine, Gervase
   Markham, Patrick McManus, Henrik Nordstrom, Yngve N.  Pettersen, Eric
   Rescorla, Thomas Roessler, Peter Saint-Andre, and Maciej Stachowiak
   for helpful comments.

7.  Informative References

   [I-D.kucherawy-dmarc-base]
              Kucherawy, M., "Domain-based Message Authentication,
              Reporting and Conformance (DMARC)", draft-kucherawy-dmarc-
              base-00 (work in progress), March 2013.

Sullivan, et al.          Expires July 11, 2015                 [Page 6]
Internet-Draft          Asserting DNS Boundaries            January 2015

   [I-D.pettersen-subtld-structure]
              Pettersen, Y., "The Public Suffix Structure file format
              and its use for Cookie domain validation", draft-
              pettersen-subtld-structure-09 (work in progress), March
              2012.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements", RFC
              4033, March 2005.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
              Security (DNSSEC) Hashed Authenticated Denial of
              Existence", RFC 5155, March 2008.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, March 2011.

   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
              April 2011.

   [publicsuffix.org]
              Mozilla Foundation, "Public Suffix List", also known as:
              Effective TLD (eTLD) List, .

              https://publicsuffix.org/

Sullivan, et al.          Expires July 11, 2015                 [Page 7]
Internet-Draft          Asserting DNS Boundaries            January 2015

Appendix A.  Discussion Venue

   This Internet-Draft is discussed on the applications area working
   group mailing list: dbound@ietf.org.

Appendix B.  Change History

   [this section to be removed by RFC-Editor prior to publication as an
   RFC]

   This is a -00 Internet-draft, but borrows from various prior draft
   works, listed below, as well as from discussions on the mailing list.

   Andrew Sullivan, Jeff Hodges: Asserting DNS Administrative
                          Boundaries Within DNS Zones

         http://tools.ietf.org/html/draft-sullivan-domain-policy-
         authority-01

         https://github.com/equalsJeffH/dbound/blob/master/draft-
         sullivan-dbound-problem-statement-00.xml

   John Levine: Publishing Organization Boundaries in the DNS

         https://tools.ietf.org/html/draft-levine-orgboundary-02

         https://github.com/equalsJeffH/dbound/blob/master/draft-levine-
         orgboundary-02.txt

   Casey Deccio, John Levine: Defining and Signaling
                          Relationships Between Domains

         http://www.ietf.org/mail-archive/web/dbound/current/
         pdfwad2AxxkYo.pdf

         http://www.ietf.org/mail-archive/web/dbound/current/
         msg00141.html

         https://github.com/equalsJeffH/dbound/blob/master/deccio-
         dbound-problem_statement-v3.pdf?raw=true

         https://github.com/equalsJeffH/dbound/blob/master/deccio-
         dbound-problem_statement-v3.txt

Sullivan, et al.          Expires July 11, 2015                 [Page 8]
Internet-Draft          Asserting DNS Boundaries            January 2015

Authors' Addresses

   Andrew Sullivan
   Dyn, Inc.
   150 Dow St
   Manchester, NH  03101
   U.S.A.

   Email: asullivan@dyn.com

   Jeff Hodges
   PayPal
   2211 North First Street
   San Jose, California  95131
   US

   Email: Jeff.Hodges@KingsMountain.com

   John Levine
   Taughannock Networks
   PO Box 727
   Trumansburg, NY  14886

   Phone: +1 831 480 2300
   Email: standards@taugh.com
   URI:   http://jl.ly

   Casey Deccio
   Verisign

   Email: casey@deccio.net

Sullivan, et al.          Expires July 11, 2015                 [Page 9]