[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 draft-levine-dbound-dns

Network Working Group                                          J. Levine
Internet-Draft                                      Taughannock Networks
Intended status: Informational                         November 18, 2015
Expires: May 21, 2016


             Publishing Organization Boundaries in the DNS
                      draft-levine-orgboundary-04

Abstract

   Often, the organization that manages a subtree in the DNS is
   different from the one that manages the tree above it.  Rather than
   describing a particular design, we describe an architecture to
   publish in the DNS the boundaries between organizations that can be
   adapted to various policy models.

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 May 21, 2016.

Copyright Notice

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

   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.



Levine                    Expires May 21, 2016                  [Page 1]


Internet-Draft               Org Boundaries                November 2015


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Design Issues . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  RRTYPE format . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Lookup Process  . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  DNS Records . . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Application scenearios  . . . . . . . . . . . . . . . . . . .   6
     6.1.  Cookies . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.2.  SSL Certificates  . . . . . . . . . . . . . . . . . . . .   6
     6.3.  DMARC . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  Variations  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   10. IANA considerations . . . . . . . . . . . . . . . . . . . . .   8
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     11.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .   9
     A.1.  Changes from -03 to -04 . . . . . . . . . . . . . . . . .   9
     A.2.  Changes from -02 to -03 . . . . . . . . . . . . . . . . .   9
     A.3.  Changes from -01 to -02 . . . . . . . . . . . . . . . . .   9
     A.4.  Changes from -00 to -01 . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Often, the organization that manages a subtree in the DNS is
   different from the one that manages the tree above it.  Many
   applications use information about such boundaries to implement
   security policies.  For example, web browsers use them to limit the
   names where web cookies can be set, and Secure Socket Layer (SSL)
   certificate services use them to determine the party responsible for
   the domain in a signing request.  Some mail security applications
   such as Domain-based Messaging Authentication, Reporting and
   Conformance (DMARC) use them to locate an organization's policy
   records in the DNS.

   [[Please direct discussion of this draft to the dbound working group
   at dbound@ietf.org.]]

2.  Design Issues

   Organization boundaries can be assigned on what one could call an
   opt-in or opt-out basis.  "Opt-in" means that two names are only
   managed by the same organization if both actively assert that they
   are related.  "Opt-out" means that if there is any boundary
   information at all for a DNS subtree, each name is assumed to be



Levine                    Expires May 21, 2016                  [Page 2]


Internet-Draft               Org Boundaries                November 2015


   under the same management as its parent unless there is a boundary
   assertion to the contrary.  This design describes an opt-out model.

   Within the opt-out model, this design can adapt to a variety of
   scenarios:

   o  Policies can be published by the domains themselves, or by a third
      party.  In the former case, each domain might assert its own
      boundary policies.  In the latter case, the third party makes the
      assertions, which may or may not agree with what the domains
      themselves would want.

   o  Multiple levels of delegation may be implemented, which is
      different from irregular boundaries.  For example, "ca", "on.ca",
      and "toronto.on.ca" are irregular boundaries, because they're all
      handled by the Canadian Internet Registration Authority (CIRA).
      CentralNIC's "uk.com" would be a second level of delegation below
      Verisign's com.

   o  Different sets of boundary rules can be published for different
      applications.  For example, the boundaries for SSL certificates
      might be different from the boundaries for e-mail policies, or for
      web cookie setting policies.

   In the lookup process below, the boundary point data is stored in the
   DNS tree in a new BOUND RRTYPE.  The boundary is considered to be
   directly below the name that the process returns, similarly to the
   names in the PSL [PSL].  If the process returned "abc.example", then
   "foo.abc.example" and "bar.abc.example" are separated by the
   boundary, but "foo.abc.example" and "foo.bar.abc.example" are not.

   Each domain publishes its own policies.

3.  RRTYPE format

   The BOUND record contains two 16-bit numeric values and an
   uncompressed domain name.  In a master file, they are written as two
   decimal values and a domain name.

   The first numeric value is a bit mask expressing policy options.  The
   only bit currently assigned is 0x0001 (NOLOWER) which means that no
   lower level boundaries can exist below this one.

   The second numeric value is a number identifying the application to
   which this boundary applies.  The number zero is a default for any
   applications not otherwise specified.





Levine                    Expires May 21, 2016                  [Page 3]


Internet-Draft               Org Boundaries                November 2015


4.  Lookup Process

   In general, the lookup process takes as input a domain name an
   application number.  It returns the name of the boundary node in the
   DNS.  This may be the domain itself or a parent.  If there is no
   policy for the domain the lookup fails; there are no defaults, and
   the DNS root is not within any organization boundary.  (Applications
   may apply defaults of their own, but that is beyond the scope of this
   specification.)

   Names of boundary information records use the tag "_bound" which is
   intended to be unique.

   For the first lookup, the client extracts the top level component
   (i.e., the rightmost label, as "label" is defined in Section 3 of
   [RFC1034]) of the domain name from the subcomponents, if any, and
   inserts the prefix in front of that component, after other components
   if any.  For example, if the domain to be checked is "example.com" or
   "www.example.com", the client issues a DNS query for
   "example._bound.com" or "www.example._bound.com".  If the domain is a
   dotless one such as "example", the client looks up "_bound.example".

   The client does a DNS lookup of BOUND records at that name, which
   will return zero or more BOUND records.  A failure such as NXDOMAIN
   is considered to return zero records.  A lookup can return multiple
   records if different applications have different boundaries or policy
   options.

   If a relevant policy record is returned, the domain name in the
   record is the policy boundary.  A policy record is relevant if it its
   application number is the application's number, or its application
   number is zero and there is no record with the application's number.
   For example, a check for a boundary above "example.com" would be
   issued at "example._bound.com", and the expected response could be
   "BOUND 0 0 com".

   If there are no boundaries below the queried point, the policy record
   contains "BOUND 1 0 ." indicating the root.  For example, if all
   subdomains of the "example" top-level domain (TLD) are under the same
   management as the TLD itself, checks for "_bound.example" or
   "www._bound.example" would return "BOUND 1 0 .".

   If the relevant record has the NOLOWER bit set, the process stops.
   Otherwise, the client inserts the prefix tag into the name just below
   (i.e., to the left of) the name at the largest matching boundary
   indicated in the lookup result, and repeats the lookup.  For example:





Levine                    Expires May 21, 2016                  [Page 4]


Internet-Draft               Org Boundaries                November 2015


   o  When evaluating "www.foo.example.com", the first query would be to
      "www.foo.example._bound.com".  If the reply to this is "BOUND 0 0
      com", then the second query would go to
      "www.foo._bound.example.com".

   o  When evaluating "www.example.on.ca", the first query would be to
      "www.example.on._bound.ca".  If the reply to this is "BOUND 0 0
      on.ca", the next lookup would be to "www._bound.example.on.ca".

   This process repeats until a DNS lookup returns a relevant record
   with the NOLOWER bit set, or a lookup returns no relevant records, at
   which point the boundary is the domain name in the last retrieved
   relevant record.

5.  DNS Records

   The publishing entity uses wildcards and prefixed names that parallel
   the regular names under a TLD to cover the domain's name space.

   If there is a boundary at a given name, an entry in the TLD record
   covers the names below it.  For example, if there is a boundary at
   ".TEST", a suitable record would be:

     *._bound.test IN BOUND 0 0 test"

   If the boundary is above the TEST domain, i.e., TEST is under the
   same management as FOO.TEST, the record would indicate no boundaries,
   and an additional non-wildcard record is needed to cover TEST itself:

     *._bound.test IN BOUND 0 0 .
     _bound.test   IN BOUND 0 0 .

   In domains with irregular policy boundaries, multiple records in the
   record describe the boundary points.  For example, in the CA (Canada)
   TLD, for national organizations there might be a boundary directly
   below the national TLD; for provincial organizations there might be a
   boundary below a provincial subdomain such as "on.ca"; and for local
   (e.g., municipal) organizations, a boundary below a municipal
   subdomain such as "toronto.on.ca" might exist.  A suitable set of of
   records covers this structure.  The closest encloser rule in RFC 4592
   [RFC4592] makes the wildcards match the appropriate names.

   *._bound.ca            IN BOUND 0 0 ca
   *.on._bound.ca         IN BOUND 0 0 on.ca
   *.toronto.on._bound.ca IN BOUND 0 0 toronto.on.ca"

   For any set of policy boundaries in a tree of DNS names, a suitable
   set of policy records can describe the boundaries, so a client can



Levine                    Expires May 21, 2016                  [Page 5]


Internet-Draft               Org Boundaries                November 2015


   find the boundary for any name in the tree with a single policy
   lookup per level of delegation.

   Since the delegation structure is unlikely to change frequently, long
   time-to-live (TTL) values in the DBOUND records are appropriate.

   If different applications have different boundaries or policy
   options, the policy records for each application are put at the
   appropriate names for the boundaries.

6.  Application scenearios

   Here are some ways that applications might use BOUND data.

6.1.  Cookies

   If an http request attempts to set a cookie for a domain other than
   the request's own domain, the client would do boundary check for the
   "cookie" application for both the request's domain and the cookie
   domain.  If they are not separated by a boundary, the request is
   allowed.

6.2.  SSL Certificates

   The client would do a boundary check for the domain name in an normal
   certificate, or the name after the "*." in a wildcard certificate for
   the "cert" application.  If the boundary is above the name, the name
   is allowed.

6.3.  DMARC

   If a DMARC lookup for the domain in a message's From: header fails,
   the client would do a boundary check for the domain name using the
   "dmarc" application.  The organizational domain is the immediate
   subdomain of the boundary domain.  (Note that the boundary will
   always be the one looked up or an ancestor.)

7.  Discussion

   The total number of DNS lookups is the number of levels of boundary
   delegation, plus one if the last boundary doesn't have the NOLOWER
   flag.  That is unlikely to be more than 2 or 3 in realistic
   scenarios, and depends on the number of boundaries, not the number of
   components in the names that are looked up.

   Some domains have very irregular boundaries.  This may require a
   large number of records to describe all the boundaries, perhaps




Levine                    Expires May 21, 2016                  [Page 6]


Internet-Draft               Org Boundaries                November 2015


   several hundred, but it doesn't seem like a number that would
   challenge modern DNS servers.

   The wildcard lookup means that each time an application looks up the
   boundaries for a hostname, the lookup results use DNS cache entries
   that will not be reused other than for subsequent lookups for the
   identical hostname.  This might cause cache churn, but it seems at
   worst no more than we already tolerate from DNSBL lookups.

8.  Security Considerations

   The purpose of publishing organization boundaries is to provide
   advice to third parties that wish to know whether two names are
   managed by the same organization, allowing those names to be treated
   "as the same" in some sense.  Clients that rely on published
   boundaries are outsourcing some part of their own security policy to
   the publisher, so their own security depends on the publisher's
   boundaries being accurate.

   Although in some sense domains are always in control of their
   subdomains, there are many situations in which parent domains are not
   expected to influence subdomains.  For example, the Internet
   Corporation for Assigned Names and Numers (ICANN) contracted global
   TLDs (gTLDs) and registers second level domains.  Since there is no
   technical bar to a parent publishing records that shadow part or all
   of the boundary record namespace for delegated subdomains, correct
   operation depends on the parent and subdomains agreeing about who
   publishes what.

   The DNS is subject to a variety of attacks.  DBOUND records are
   subject to the same ones as any other bit of the DNS, and the same
   responses, such as using DNSSEC, apply.

9.  Variations

   Since nothing but BOUND records should be published at names with
   _bound components, one could get the same effect with TXT records,
   e.g.:

     *.toronto.on._ob.ca IN TXT "bound=1 0 0 toronto.on.ca"

   The "bound=1" tag is to prevent confusion when a domain publishes a
   wildcard such as *.example.com that could match a _bound name.

   If third parties wanted to publish boundary information, they could
   do it in their own subtree of the DNS.  For example, if
   polgroup.example were publishing boundary information about
   boundaries, the records for the test domain described above would be:



Levine                    Expires May 21, 2016                  [Page 7]


Internet-Draft               Org Boundaries                November 2015


     *._bound.test.polgroup.exaple IN BOUND 0 0 .
     _bound.test.polgroup.example  IN BOUND 0 0 .

10.  IANA considerations

   This document defines a new DBOUND RRTYPE.  IANA has assigned value
   TBD.

   This document requests that IANA create a registry of BOUND Flag
   Bits.  Its registration policy is IETF Review.  Its initial contents
   are as follows.  [[NOTE: new flags are likely to change the lookup
   algorithm]]

     +------------------+-----------------+-------------------------+
     |       Bit        | Reference       | Description             |
     +------------------+-----------------+-------------------------+
     | 0x0001 (NOLOWER) | (this document) | No lower level policies |
     +------------------+-----------------+-------------------------+

                  Table 1: BOUND Flag Bits Initial Values

   This document requests that IANA create a registry of BOUND
   Applications.  Its registration policy is First Come First Served.
   Its initial contents are as follows.  [[Note: New applications don't
   affect the lookup process, and shouldn't affect existing
   applications.]]

      +------------+-----------------+------------------------------+
      |   Value    | Reference       | Description                  |
      +------------+-----------------+------------------------------+
      |  0 (Any)   | (this document) | Any application              |
      | 1 (Cookie) | (this document) | HTTP web cookies             |
      |  2 (Cert)  | (this document) | SSL certificate authorities  |
      | 3 (DMARC)  | (this document) | DMARC organizational domains |
      +------------+-----------------+------------------------------+

                Table 2: BOUND Applications Initial Values

11.  References

11.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <http://www.rfc-editor.org/info/rfc1034>.






Levine                    Expires May 21, 2016                  [Page 8]


Internet-Draft               Org Boundaries                November 2015


   [RFC4592]  Lewis, E., "The Role of Wildcards in the Domain Name
              System", RFC 4592, DOI 10.17487/RFC4592, July 2006,
              <http://www.rfc-editor.org/info/rfc4592>.

11.2.  Informative References

   [PSL]      Mozilla Foundation, "Public Suffix List", Nov 2015.

Appendix A.  Change Log

   *NOTE TO RFC EDITOR: This section may be removed upon publication of
   this document as an RFC.*

A.1.  Changes from -03 to -04

   Editorial changes, fix speling errors.

A.2.  Changes from -02 to -03

   New BOUND record type and modified lookup procedure.

A.3.  Changes from -01 to -02

   Add ABNF.

   MSK overhaul of the middle part.

   Put the wildcards back.

A.4.  Changes from -00 to -01

   Take out wildcards and put everything in one record.

   Add DNS nits.

Author's Address

   John Levine
   Taughannock Networks
   PO Box 727
   Trumansburg, NY  14886

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






Levine                    Expires May 21, 2016                  [Page 9]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/