Organizational Domains and Use Policies for Domain Names
draft-deccio-dbound-organizational-domain-policy-00

Abstract

Various Internet protocols and applications require some mechanism for identifying policy surrounding the use Domain Name System (DNS) names. In this document we describe an extensible system in which domain name policies can be discovered at various levels in the DNS tree.

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 April 15, 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.

Table of Contents

• 1. Introduction
• 2. Solution Concepts
• 3. Designating Organizational Domain and Use Policy
• 3.1. ODUP Name
• 3.2. ODUP Statement
• 3.2.1. Version
• 3.2.2. Directives
• 3.3. org and bound Directives
• 4. Identifying Organizational Domain and Use Policy
• 4.1. Wildcards
• 5. Policy-negative Realm
• 5.1. PSL/ODUP Equivalence Example
• 5.2. _odup DNS Zone
• 6. Examples
• 6.1. ODUP Resolution
• 7. Example Application Use
• 7.1. Public Suffix List Replacement
• 7.2. HTTP Cookies
• 7.3. DMARC
• 8. Contributors
• 9. IANA Considerations
• 10. Security Considerations
• 11. References
• 11.1. Normative References
• 11.2. Informative References
• Appendix A. Pseudo-code for ODUP Resolution
• Author's Address

1. Introduction

The concepts of domains, subdomains, and administrative delegation are fundamental to the Domain Name System (DNS) [RFC1034] [RFC1035]. The DNS namespace is hierarchical, and the management of subdomain space is delegated by one entity to another throughout. However, policies governing the use of domain names do not always align with those lines of delegation. There are currently no generally reliable methods to reconcile domain names with policy for their use.

As a prominent example, HTTP cookies [RFC6265] have traditionally used ancestral relationships to determine allowable scope of information sharing and authorization. For example, the server at www.example.com might set a cookie with a Domain attribute of example.com, because it is a subdomain of that name. However, this simplistic authorization does not account for some cases, such as cookies with a Domain attribute corresponding to a so-called "public suffix". [RFC6265] indicates that many user agents reject such cookies due to security and privacy concerns. Even so, the public suffix designation is not apparent from either the names themselves or the delegations leading down to them from the root. Instead, a resource, such as Mozilla's Public Suffix List (PSL) [PSL], is used to identify public suffixes.

Another challenge with domain names is the ability to identify their respective Organizational Domains, for applications like Domain-based Message Authentication, Reporting, and Conformance (DMARC) [RFC7489]. [RFC7489] includes heuristics to identify an organizational domain using a public suffix list (e.g., Mozilla's PSL [PSL]) "in the absence of more accurate methods". Other applications have similarly relied on a public suffix list to define an organizational domain, whether for policy, forensics, or simple identification. However, defining a "more accurate" method is desirable.

In this document we describe a framework for more accurately identifying policy and organizational domains on a per-domain name basis. The system described adds customization and flexibility to existing systems while being fully backwards compatible with previous mechanisms and default behaviors.

2. Solution Concepts

The major questions to be addressed by a solution in this space are the identification of policy for a given domain name and the identification of an organizational domain for a given domain name. The questions are related in that the policy for a domain name might depend on its organizational domain name, either because that policy is defined by its organizational domain or because it depends on organizational boundaries.

In previous solutions, policy has almost always been bound by direct ancestral relationships. While that constraint might be lifted by future solutions, the solution documented herein respects the hierarchical order in the DNS: policies between domain names in which one is not a sub-domain of the other are non-existent and out of scope for this document.

In this context the organizational domain for a given domain name will always be an ancestor of the domain name, if not the domain name itself. Prior to this draft, one of the heuristics for determining the organizational domain was using a public suffix list: the organizational domain is the series of labels comprising the public suffix portion of the name, plus one label ([RFC6265]). With that methodology, for any given domain name, not a public suffix, there was exactly one possible organizational domain. In this work, an organizational domain can be designated at (mostly) arbitrary levels in the domain name's ancestry.

The notion of a "public suffix" (i.e., as included in a public suffix list, such as Mozilla's PSL [PSL]) has brought to light the nature of policy associated with "registry controlled domains" ([RFC6265]), sometimes viewed as extensions of top-level domains, which have similar policy. While domain names might appear in current versions of such lists for a variety of reasons, the impact of their designation is consistent: they are treated as special-purpose names, limited in their use by applications. For example, HTTP cookies with a Domain attribute corresponding to a public suffix are rejected by most user agents. Similarly, public suffixes cannot be organizational domains, e.g., for DMARC use. We refer to the set of names above the boundary separating public suffixes from their descendants as "policy-negative".

3. Designating Organizational Domain and Use Policy

In this section we describe the technical implementation for designating organization domain and use policy (ODUP) for domain names.

3.1. ODUP Name

The "_odup" label, when used as part of a domain name, carries special meaning in the context of defining organizational domains and policy, and the resulting domain name is referred to as an ODUP name. In an ODUP name the sequence of labels after the _odup label (i.e., higher in the DNS namespace tree) comprise the organizational domain, and the concatenation of the sequence of labels before it (i.e., lower in the DNS namespace tree) with those after it comprise the policy domain.

For example, given the ODUP name foo.bar._odup.example.com, the organizational domain is example.com, and the policy domain is foo.bar.example.com.

3.2. ODUP Statement

A TXT record at an ODUP name contains an ODUP statement for the policy domain.

3.2.1. Version

The ODUP statement begins with a version declaration. At this time, the only defined version is "odup1", so the record MUST begin with "v=odup1".

3.2.2. Directives

Following the version declaration and a space is a series of zero or more space-separated directives, each prepended with a qualifier, "+" or "-". Defined directives include the following:

• httpcookie - whether the domain name may (+) or may not (-) be used as the value of the Domain attribute of an HTTP Cookie.
• tlscert - whether (+) or not (-) this domain name may be used in a TLS certificate.
• wildcardtlscert - whether (+) or not (-) a wildcard name directly under this domain name may be used in a TLS certificate.
• all - for directives not otherwise specified, the default policy is allow (+) or deny (-).

The following directives do not carry policy information, but designate organizational domains or boundaries. Only the "+" qualifier is valid with these directives:

• org - specifies that the policy domain itself is an organizational domain.
• bound - designates an organizational boundary immediately below the policy domain, indicating that domain names below the policy domain (i.e., proper subdomains) are themselves organizational domains.

When the "org" or "bound" directives are used in an ODUP statement, they MUST NOT appear together in the same statement. Additionally, the "org" directive SHOULD NOT be accompanied by any other directives; any other directives MUST be ignored by software interpreting the statement.

An ODUP statement MUST NOT have more than one "all" directive (with its accompanying qualifier). If no "all" directive is supplied, an implicit "+all" is applied.

The "all" directive SHOULD appear last in an ODUP statement. This is for readability purposes only, as directive order otherwise doesn't matter.

Because the "all" directive specifies the default policy for a given policy domain, other directives in the same statement simply specify exceptions to that default policy. Thus, the qualifier for any directives other than "all" SHOULD be the opposite as that used with "all". The only side effect to non-adherence to this recommendation is the existence of superfluous directives (i.e., because they are already implied with the default policy). Implementors MAY add such directives nonetheless, for added readability.

3.3. org and bound Directives

The "org" and "bound" directives of an ODUP statement are similar to each other but serve different purposes and ultimately have different semantics. They are similar in the sense that they are delegating organizational domain and policy information to subdomains. They differ in that the "org" directive designates a specific domain name as an organizational domain, but the "bound" directive only specifies the boundary below which domain names are organizational domains. These differences result in additional ramifications, described below.

Because the "org" directive names a domain name as an organizational domain, subdomains of ODUP names whose statements include the "org" directive SHOULD NOT exist, and subdomains MUST NOT be queried for policy.

For example, if the ODUP statement for example._odup.com is "v=odup1 +org", then example.com is an organizational domain, and further policy information would be sought in the "_odup.example.com" domain. The domain name foo.example._odup.com is irrelevant.

However because the "bound" directive specifies only a boundary, and the boundary may exist at different levels in the domain name space, subdomains of ODUP names whose statements include "bound" are allowed and (as described later) are queried to find the most specific policy domains (i.e., longest match).

For example, if the ODUP statement for example._odup.com is "v=odup1 +bound", more specific policy information might be found in the foo.example._odup.com ODUP name.

"bound" directives SHOULD only be used in the policy-negative realm (see Section 5). In other places, the same effect can typically be accomplished through use of the "org" directive.

4. Identifying Organizational Domain and Use Policy

The process of identifying organizational domains and policies is referred to as ODUP resolution. It involves methodically issuing DNS queries for DNS records of type TXT at ODUP names. The desired outcome for ODUP resolution is an organizational domain, a policy domain, and a policy. The process is iterative, eventually finding the ODUP statement corresponding to the policy name that mostly closely matches the domain name being looked up within the lowest designated organizational domain. Each iteration is as follows, beginning with the root as the organizational domain:

1. If the organizational domain has the same number of labels as the domain name in question, then return the result of querying for the TXT record at the ODUP name formed by prepending "_odup" to the organizational domain. Otherwise, continue.
2. Beginning with the policy domain formed by using just one label below the organizational domain, increasing the number of labels with each iteration, form an ODUP name.
3. Query the ODUP name formed in the previous step for a record of type TXT.
4. If the query results in a positive response, then save the query as longest matching record.
5. If the query results in a positive response with an "org" directive, then continue to step Step 10.
6. If the query results in a positive response that includes a "bound" directive, and the response is derived from a wildcard, continue to Step 10.
7. If the query is a name error response then continue to Step 10.
8. If all the labels have been exhausted, then go to Step 10.
9. Return to step Step 2, increasing the number of labels of policy domain.
10. If there was no positive response, then return to Step 1 using the current organizational domain as both the policy domain and organizational domain.
11. If the longest matching record includes an "org" directive, then return to Step 1, using the longest matching policy domain as the organizational domain.
12. If the longest matching record includes an "bound" directive, then return to Step 1, using the longest matching policy domain, plus one label, as the organizational domain.
13. Return the record corresponding to the longest matching policy domain.

Appendix A contains the pseudo-code for this algorithm.

4.1. Wildcards

Just as with other DNS names and record types, wildcard ODUP names can be used to designate policy for arbitrary subdomain ODUP names. However, in ODUP resolution, wildcard detection MUST be used. Specifically, iteration MUST NOT continue beyond the first label of an expanded wildcard if the response yielded an ODUP statement containing the "bound" directive. This is to prevent the case where a boundary is designated using the "bound" directive, but in searching for the longest match, the boundary is bypassed.

Wildcard detection MAY also be used to stop iteration even on directives that don't contain the "bound" directive, as it might help increase privacy, as suggested in Section 10.

Wildcards may be detected by issuing a second lookup in response to a positive DNS response, substituting the left-most label of the ODUP name with "*". The responses should conform to [RFC4592]. Or if the record is signed with DNSSEC, then the presence of a wildcard can be detected by examining the value of the "labels" field of the accompanying RRSIG record [RFC4034].

Note that because "bound" directives are nearly exclusive to the policy-negative realm (see Section 3.3), the overhead associated with compulsory wildcard lookup can be avoided almost in its entirety by using a local copy, in which lookups are avoided altogether, as suggested in Section 5.

5. Policy-negative Realm

The policy-negative realm is the portion of the DNS namespace that corresponds to so-called public suffixes. The ODUP policies defining the policy-negative realm fall under the organizational domain corresponding to the root domain name (i.e., they are subdomains of the ODUP name _odup) and consist of ODUP statements that use the "bound" directive.

The policy at the root domain name itself, as contained in the TXT record at the ODUP name "_odup", is "v=odup1 +bound -all", indicating a global "deny" policy and an initial boundary below the root domain name. Directives other than "bound" and "-all" MUST NOT be used in the policy-negative realm.

The result is that the ODUP statements defining the policy-negative realm comprise a PSL-like list. In fact, the statements comprising the policy-negative realm can be derived from Mozilla's [PSL] and vice-versa. See, for example, the tables in Section 5.1. This is useful for several reasons. The current applications and libraries using the PSL have a way to work in parallel, one being derived from the other, for backwards compatibility and possible transition. It also enables consumer applications to work offline by simply downloading all the policy-negative statements when those are sufficient for the purposes of the application.

Even when a self-contained listing of the policy-negative names is locally available but insufficient for the needs of the consumer application (i.e., a more specific assurance of policy is necessary), this resource can provide an efficient starting place for ODUP resolution. Rather than starting with the root domain name as the organizational domain, the shortest organizational domain below the policy-negative boundary is used first. This increases efficiency by avoiding network latency associated with unnecessary DNS lookups.

5.1. PSL/ODUP Equivalence Example

5.2. _odup DNS Zone

ODUP resolution introduces a new label, _odup, under the DNS root. Technically speaking, this doesn't create any problems, as it is simply treated as another node in the DNS, even though it doesn't fit the mold of other top-level domains. This is in large part because there are no DNS delegations (i.e., via NS records).

All ODUP names within the policy-negative realm and thus under the root-level organizational domain exist under the _odup top-level domain. This means that the entire set of records comprising the policy-negative realm can be maintained as the contents of a single DNS zone.

Maintaining the policy-negative realm as a DNS zone has several advantages. The zone contents can be maintained, published, and accessed in a well-known format. For example, in addition to providing responses to normal DNS queries, it might be made available via zone transfers, or for download over HTTP. Additionally, the fact that a zone has a serial (as a field in the record data of the SOA record), applications can determine through a query of type SOA whether the contents of the policy-negative realm have changed.

The hosting and maintenance of the _odup DNS zone might appropriately be the joint responsibility of the Internet Assigned Numbers Authority (IANA)[IANA] and the CA/Browser Forum[CAB-Forum].

6. Examples

We provide several examples and in this section of ODUP designation, resolution, and potential application.

6.1. ODUP Resolution

Example DNS entries are listed in Table 1 and illustrated in Figure 1. The resulting policies are listed in Table 2.

                               .
                               |
                              uk
                         /     |    \
                       /       |      \
                    --+--      |        \
                      a       co        sch
                      |        |         |
                    /   \    --+--       h
                   b     e *   g         |
                   |     |             --+--
                 --+--   f               i
                   c *
                   |
                   d
					

function resolveODUP(N = [l(n)...l(1)], orgBoundary)
{
    Require: N = [l(n)...l(1)], n >= 0
      (a sequence of labels representing domain name, N)
    Require: orgBoundary, 0 <= orgBoundary <= n
      (an integer representing an index into N)
    Return: a three-tuple consisting of:
      - policyDomain, the domain name from the which the policy
        was derived
      - orgDomain, the organizational domain of N
      - policy, the raw policy resulting from TXT DNS queries

    if orgBoundary = 0
    {
        // orgDomain is the root and contains no labels
        orgDomain := []
    }
    else
    {
        // orgDomain consists of labels 1 through orgBoundary
        orgDomain := [l(orgBoundary)...l(1)]
    }

    if orgBoundary = n
    {
        // Base case: orgDomain is composed of all labels

        testDomain := ["_odup"] | orgDomain
        queryResult := queryDNS(testDomain, "TXT")
        if queryResult is an answer
        {
            // return the contents of the TXT record
            return orgDomain, orgDomain, queryResult
        }
        else
        {
            // return an empty policy
            return orgDomain, orgDomain, ""
        }
    }

    subDomainLabels := n - (orgBoundary + 1)
    longestMatch := NULL
    longestMatchBoundary := NULL
    for all i in [0...subDomainLabels]
    {
        subDomain := [l(orgBoundary + 1 + i)...l(orgBoundary + 1)]
        testDomain := subDomain | ["_odup"] | orgDomain
        queryResult := queryDNS(testDomain, TXT)
        if queryResult is an answer
        {
            // Set longestMatch to the value of queryResult
            longestMatch := queryResult
            longestMatchBoundary := i
            if queryResult includes "+org"
            {
                // If this was a organizational domain designation,
                // then don't go any further; the organization will
                // dictate policy
                break
            }
            if queryResult includes "+bound" AND
                was synthesized from wildcard
            {
                // If this was a boundary designation, and the answer
                // was synthesized from a wildcard, no further
                // lookups must be performed
                break
            }
        }
        else if queryResult is NXDOMAIN
        {
            // An NXDOMAIN result means that no further lookups are
            // necessary, as there is no subtree
            break
        }
    }

    if longestMatch is not NULL
    {
        // If a policy has been found, then look for +org or +bound
        // directives, which indicate that the organizational domain and
        // policy are (at least) one or two levels lower than the value
        // of longestMatchBoundary, respectively.  resolveODUP is then
        // called recursively.
        if longestMatch includes "+org"
        {
            return resolveODUP([l(n)...l(i)], longestMatchBoundary + 1)
        }
        else if longestMatch includes "+bound" and orgBoundary + 2 <= n
        {
            return resolveODUP([l(n)...l(i)], longestMatchBoundary + 2)
        }

        // With no +org or +bound directives present, the orgDomain and
        // policy remain as they were looked up, and are returned with
        // the policy domain
        return [l(longestMatchBoundary)...l(1)], orgDomain, longestMatch
    }
    else
    {
        // There is no more specific policy for the given name, so
        // return the policy for the orgDomain
        return resolveODUP(orgDomain, orgBoundary)
    }

}