draft-levine-orgboundary-02.txt

Network Working Group                                          J. Levine
Internet-Draft                                      Taughannock Networks
Intended status: Informational                             July 31, 2013
Expires: February 01, 2014


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

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 February 01, 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 February 01, 2014               [Page 1]

Internet-Draft               Org Boundaries                    July 2013


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Design Issues . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Lookup Process  . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Record Syntax . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  DNS Records . . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .   8
     A.1.  Changes from -01 to -02 . . . . . . . . . . . . . . . . .   8
     A.2.  Changes from -00 to -01 . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

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 Authetnication, Reporting and
   Conformance (DMARC) use them to locate an organization's policy
   records in the DNS.

   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 location, with some libraries
   available to parse and search it.  While it has worked adequately, it
   has a variety of issues:

   1.  Processing the file is relatively slow, so adequate performance
       requires that each application cache a copy of the file.

   2.  The file is in a unique format that requires a specialized parser
       and lookup routines.

   3.  The file is managed by a third party rather than directly by the
       domain owners, meaning the likelihood of stale data is a concern.









Levine                  Expires February 01, 2014               [Page 2]

Internet-Draft               Org Boundaries                    July 2013


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
   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 TXT
   records.  While it wouldn't be harmful to use a new RRTYPE, it would
   also provide little benefit: All of the DNS names used include a
   distinctive prefixed name component, so there should not be any
   resource records at those names other than the TXT record for the
   boundary.  To avoid confusion due to top-level wildcard records that
   might inadvertently cover the subtree of boundary records, the TXT
   strings contain a prefix tag.

3.  Lookup Process

   The DNS protocol is defined in [RFC1034] and [RFC1035].  The query is
   for RRTYPE 15 (TXT).

   Each collection of boundary data has a "base name" and a "prefix
   tag".




Levine                  Expires February 01, 2014               [Page 3]

Internet-Draft               Org Boundaries                    July 2013


   The base name is a location in the DNS tree where the organizational
   boundary data is rooted.  In particular, the "official" boundary data
   has a base name of "." (the DNS root), while using some other base
   name implies the owner of the base name is the party making
   organizational boundary assertions.

   The prefix tag is the string "_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" for conventional HTTP cookies, or
   "_dmarc._ob" for organizational boundaries intended to be used only
   within the context of the DMARC protocol.  [[TBD: Add a DMARC
   reference.]].  Note that due to the way wildcard matches, a query for
   a specific boundary type will match the general boundary type if
   there is no specific boundary. [[ I think this also falls out
   correctly even when there are also non-wildcard records, but I need
   to check that, ]]

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

   In general, the lookup process takes as input a domain name and
   returns the name of the node in the DNS closest to the root that also
   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
   (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._ob.com" or "www.example._ob.com".  If the domain is simply
   "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 name
   "cookies.example", the full queried name would be
   "example._ob.com.cookies.example."

   If a valid policy record is returned, the contents of the record
   after the required prefix string comprise the domain name at or just
   below the policy boundary.  For example, a check for a boundary
   between "com" and "example.com" would be issued at "example._ob.com",
   and the expected response would be "ob=1 com".



Levine                  Expires February 01, 2014               [Page 4]

Internet-Draft               Org Boundaries                    July 2013


   If there are no boundaries below the queried point, the policy record
   contains "ob=1 ." 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 "_ob.example" or
   "www._ob.example" would return "ob=1 .".

   If the client process only handles a single level of delegation, the
   process stops after a single lookup.  If it allows multiple levels of
   delegation, 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:

   o  When evaluating "www.foo.example.com", the first query would be to
      "www.foo.example._ob.com".  If the reply to this is "ob=1 com",
      then the second query would go to "www.foo._ob.example.com".

   o  When evaluating "www.example.on.ca", the first query would be to
      "www.example.on_ob.ca".  If the reply to this is "ob=1 on.ca", the
      next lookup would be to "www._ob.example.on.ca".

   This process repeats until a DNS lookup returns NXDOMAIN (DNS RRCODE
   3), at which point the result of this algorithm is the domain name
   that last returned a successful query with the first label ("_ob")
   removed.

   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 most
   realistic scenarios.

4.  Record Syntax

   Expressed in ABNF ([RFC5234]), the syntax of a reply is as follows:

   ob-reply = "ob=1 " ("." | Domain )


   "Domain" is defined in Section 4.1.2 of [RFC5321].

5.  DNS Records

   The publishing entity uses wildcards and 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:




Levine                  Expires February 01, 2014               [Page 5]

Internet-Draft               Org Boundaries                    July 2013


   *._ob.test IN TXT "ob=1 test"


   If the boundary is at 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:

   *._ob.test txt "ob=1 ."
   _ob.test   txt "ob=1 ."


   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.

   *._ob.ca            txt "ob=1 ca"
   *.on._ob.ca         txt "ob=1 on.ca"
   *.toronto.on._ob.ca txt "ob=1 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.

   Since the delegation structure is unlikely to change with any
   frequency, very long time-to-live (TTL) values in the organizational
   boundary records are appropriate.

6.  Discussion

   Some domains have very irregular boundaries.  This may require a
   large number of records to describe all the boundaries, perhaps
   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.




Levine                  Expires February 01, 2014               [Page 6]

Internet-Draft               Org Boundaries                    July 2013


   The record format described above uses dots as reserved characters to
   indicate the boundaries between labels in names.  This is adequate if
   policies only apply to host names, but if becomes 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.  So the last record above would be
   represented as:

   *.toronto.on._ob.ca IN TXT "ob=1" "toronto" "on" "ca"


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

8.  Normative 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.

   [RFC4592]  Lewis, E., "The Role of Wildcards in the Domain Name
              System", RFC 4592, July 2006.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.



Levine                  Expires February 01, 2014               [Page 7]

Internet-Draft               Org Boundaries                    July 2013


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 -01 to -02

   Add ABNF.

   MSK overhaul of the middle part.

   Put the wildcards back.

A.2.  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 February 01, 2014               [Page 8]