Publishing organization boundaries in the DNS
draft-levine-orgboundary-01

Network Working Group                                          J. Levine
Internet-Draft                                      Taughannock Networks
Intended status: Informational                             July 07, 2013
Expires: January 08, 2014

             Publishing organization boundaries in the DNS
                      draft-levine-orgboundary-01

Abstract

   Often, the organization that manages a subtree in the DNS is 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 January 08, 2014.

Copyright Notice

   Copyright (c) 2013 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 January 08, 2014                [Page 1]
Internet-Draft               Org Boundaries                    July 2013

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Design issues . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Lookup process  . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  DNS records . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Nitpicky DNS notes  . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security considerations . . . . . . . . . . . . . . . . . . .   5
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Often, the organization that manages a subtree in the DNS is 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.  SSL certificate services use
   them to determine the responsible party for the domain in a signing
   request.  Some mail security applications such as DMARC use them to
   locate an organization's policy records.

   The most widely used source of boundary data is the Public Suffix
   List, maintained by the Mozilla Foundation.  It is distributed as a
   text file available at a well known URL, with some libraries to parse
   and search it.  While it has worked adequately, it has a variety of
   issues.  Downloading the file is relatively slow, and adequate
   performance requires that each application cache a copy of the file.
   The file is in a unique format that requires a specialized parser and
   lookup routines.  The file is managed by a third party rather than
   directly by the domain owners, which may or may not be considered a
   problem.

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 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
   design points.

   Policies can be published by the domains themselves, or by a third
   party.  In the former case, each domain might assert its own boundary

Levine                  Expires January 08, 2014                [Page 2]
Internet-Draft               Org Boundaries                    July 2013

   policies.  In the latter case, the third party makes the assertions,
   which may or may not agree with what the domains themselves would
   want.

   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 CIRA.
   CentralNIC's uk.com would be a second level of delegation below
   Verisign's com.

   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 TXT
   records.  While it wouldn't hurt anything to use a new RRTYPE, it
   wouldn't be useful.  All of the DNS names used include a distinctive
   prefixed name component, so there shouldn't be any RRs at those names
   other than the TXT record for the boundary.  To avoid confusion due
   to top-level wildcards that might inadvertently cover the subtree of
   boundary records, the TXT strings contain a prefix tag.

3.  Lookup process

   Each collection of boundary data has a base name and a prefix tag.
   If domains publish their own information, the base name is the DNS
   root.  Otherwise it is a domain belonging to the publishing entity.
   The tag is _ob and is intended to be unique.  If there are different
   kinds of boundary data, the tag can be further prefixed, e.g.,
   _cookie._ob or _dmarc._ob.

   Every valid policy record starts with a fixed prefix "ob=1 " for
   organization boundary version 1.  If a lookup returns no TXT records
   that start with the prefix, or more than one record that starts with
   the prefix, the lookup fails.

   The lookup process takes a domain name and returns the name of the
   node closest to the root that belongs to the same organization.  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.)

   For the first lookup, the client extracts the top level component of
   the domain name from the subcomponents, if any, and inserts the
   prefix in front of the top level component.  For example, if the

Levine                  Expires January 08, 2014                [Page 3]
Internet-Draft               Org Boundaries                    July 2013

   domain to be checked is example.com or www.example.com, the client
   looks up _ob.com.  If the domain is just example, the client looks up
   _ob.example.  If the base name is not null, it is appended to the
   name to be looked up, so if the name example.com were to be checked
   in a collection with the base cookies.example, the name looked up
   would be _ob.com.cookies.example.

   If the lookup returns a valid policy record, the contents of the
   record disregarding the prefix are the domain names just above the
   policy boundaries.  For example, if there is a boundary between
   example.com and the com TLD, the record would contain "ob=1 com" when
   checking example.com or www.example.com.  If a domain has multiple
   boundaries, the record contains a space separated list of the
   boundary points, e.g., "ob=1 ca on.ca toronto.on.ca".

   If there are no boundaries below the TLD, the policy record contains
   "." for the root.  For example, if all subdomains of the "example"
   TLD are under the same management as the TLD itself, checks for
   _ob.example would return "ob=1 .".

   If the lookup process only allows a single level of delegation, the
   process stops after a single lookup.  If it allows multiple levels of
   delegation, the client prefixes the tag to the name just below the
   name below the boundary just found and repeats the lookup.  For
   example, if the domain in question is www.foo.example.com, and a
   lookup of _ob.com returned "ob=1 com", the next lookup would be
   _ob.example.com.  or if the domain were www.example.on.ca, and a
   lookup of _ob.ca returned "ob=1 ca on.ca toronto.on.ca" the next
   lookup would be _ob.example.on.ca.  This process repeats until a DNS
   lookup returns NXDOMAIN, at which point the result is the result of
   the last successful lookup.  The total number of DNS lookups is the
   number of levels of boundary delegation, which is unlikely to be more
   than 1 or 2 in realistic scenarios.

4.  DNS records

   The publishing entity uses prefixed names that parallel the regular
   names under a TLD to cover the relevant name space.

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

   _ob.test txt "ob=1 test"

   If the boundary is at the .TEST domain, i.e., TEST. is under the same
   management as FOO.TEXT, the record would indicate no boundaries:

Levine                  Expires January 08, 2014                [Page 4]
Internet-Draft               Org Boundaries                    July 2013

   _ob.test txt "ob=1 ."

   In domains with irregular policy boundaries, multiple strings in the
   record describe the boundary points.  For example, in the .CA TLD,
   for national organizations there might be a boundary directly below
   the TLD, for provincial organizations a boundary below a provincial
   subdomain such as on.ca, and for local organizations, a boundary
   below a municipal subdomain such as toronto.on.ca.  A suitable list
   of names covers this structure.  The boundary is the longest boundary
   point that matches a suffix of the domain name.  (Note: "longest"
   means longest, like, you know, the most characters.)

   _ob.ca txt "ob=1 ca on.ca 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
   find the boundary for any name in the tree with a single policy
   lookup per level of delegation.

5.  Nitpicky DNS notes

   Some domains have very irregular boundaries.  For example, the .CA
   domain has boundaries ten provinces and probably a hundred
   municipalities, so the record for _ob.ca would be quite long,
   probably requiring a fallback to TCP for clients that don't support
   EDNS0.  While it would be possible to break the record up into
   smaller pieces that fit in 512 bytes and reassemble them, it's
   probably not worth the hassle, and slower than a short TCP session.

   The record format described above uses spaces and dots as reserved
   characters to indicate the boundaries between names and between name
   components.  This is adequate if policies only apply to host names,
   but if it's important to allow arbitrary names, it would be easy to
   encode them in TXT records.  Keeping in mind that a TXT record
   contains a sequence of strings, each preceded by a count byte, each
   component of the name is represented as a string, and the boundary
   between names is represented by a zero-length string.  So the record
   above would be represented as

   _ob.ca txt "ob=1" "ca" "" "on" "ca" "" "toronto" "on" "ca"

6.  Security considerations

   The point of publishing organization boundaries is to provide advice
   to third parties that wish to know whether two names are managed by

Levine                  Expires January 08, 2014                [Page 5]
Internet-Draft               Org Boundaries                    July 2013

   the same organization so the names can be treated "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 mess with child subdomains, e.g., ICANN contracted gTLDs
   and registered 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.

7.  Informative References

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

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 January 08, 2014                [Page 6]