Internet DRAFT - draft-deccio-dbound-name-relationships
draft-deccio-dbound-name-relationships
Internet Engineering Task Force C. Deccio
Internet-Draft Verisign Labs
Intended status: Informational J. Levine
Expires: January 7, 2016 Taughannock Networks
July 6, 2015
Concepts for Domain Name Relationships
draft-deccio-dbound-name-relationships-00
Abstract
Various Internet protocols and applications require some mechanism
for identifying relationships between Domain Name System (DNS) names.
In this document we provide examples of protocols and applications
for which knowledge of these relationships is useful, if not
required. Further we discuss the various types of domain name
relationships, review current needs and solutions, and identify
considerations for solution sets.
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 7, 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
Deccio & Levine Expires January 7, 2016 [Page 1]
Internet-Draft Concepts for Domain Name Relationships July 2015
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Domain Name Concepts . . . . . . . . . . . . . . . . . . . . . 3
2.1. Domain Names . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Domain Name Scope . . . . . . . . . . . . . . . . . . . . 4
2.2.1. Public/private Boundaries . . . . . . . . . . . . . . 4
2.3. Domain Name Relationships . . . . . . . . . . . . . . . . 4
3. Policy-based Domain Name Relationships . . . . . . . . . . . . 5
3.1. Cross-Scope Policy Relationships . . . . . . . . . . . . . 5
3.2. Intra-Scope Policy Relationships . . . . . . . . . . . . . 5
3.2.1. Public-public Policy Relationships . . . . . . . . . . 6
3.2.2. Private-private Policy Relationships . . . . . . . . . 6
4. Known Applications Requiring Identification of
Policy-based Domain Relationships . . . . . . . . . . . . . . 6
4.1. HTTP Cookies . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Email sender verification . . . . . . . . . . . . . . . . 7
4.3. SSL certificate requests . . . . . . . . . . . . . . . . . 7
5. Public Suffix List . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Known Application Usage . . . . . . . . . . . . . . . . . 9
6. Solution Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Informative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Deccio & Levine Expires January 7, 2016 [Page 2]
Internet-Draft Concepts for Domain Name Relationships July 2015
1. Introduction
The use of various Internet protocols and applications has introduced
the desire and need for designated relationships between Domain Name
System (DNS) names, beyond the lineal relationship inherent in the
names themselves. While protocols, such as that used by HTTP
Cookies, have traditionally used ancestral relationships to determine
allowable scope of information sharing and authorization, there is an
increasing need to identify relationships between arbitrary domains.
We begin by establishing terminology and concepts, after which we
discuss known applications for which the identification of domain
name relationships are desirable or required. We then discuss the
Public Suffix List, the primary solution for domain relationships
currently available. Finally, we recommend considerations for
solutions in this problem space.
2. Domain Name Concepts
For consistency in language we define terms and concepts surrounding
domain names.
2.1. Domain Names
A DNS domain name is represented as sequence of dot-separated labels,
such as www.example.com (i.e., comprised of labels "www", "example",
and "com"). This sequence corresponds to the list of the labels
formed by traversing the tree representing the domain name space,
from the node representing the name itself to the root (top) of the
tree ([RFC1034]). In this tree context, we thus refer to domain
name's parent as the domain name formed by removing the leftmost
label (i.e., the domain name corresponding to the node directly above
it in the tree). The parent of www.example.com is example.com.
As there are no requirements or inferences surrounding delegation
(i.e., zone cut) at any point in the DNS tree, there are no
assumptions in this document about administrative boundaries drawn by
delegations, unless explicitly stated otherwise. That is to say that
this document considers DNS names independently from their
administration, as defined by the DNS.
As noted in [RFC1034], the term "domain name" is used in contexts
outside the DNS. The scope of this document is limited to domain
names as defined by the DNS.
Deccio & Levine Expires January 7, 2016 [Page 3]
Internet-Draft Concepts for Domain Name Relationships July 2015
2.2. Domain Name Scope
The use of domain names in various applications over time has
produced a notion of scope, which we use to refer to the general
ability of arbitrary entities to register children of a domain name
(i.e., create child nodes in the domain name tree). In some contexts
these are called "public suffixes" or "registry controlled domains"
([RFC6265]). For example, children of the top-level domain (TLD)
com, are generally registrable by arbitrary entities, which puts the
com domain name in the public scope. However, com's children are
typically not used in the same fashion (though certainly there are
exceptions), which puts them largely in the private scope.
The children of public domain names may either be in public or
private scope; likewise the children of private domain names may
either be in public or private scope.
While zone cuts often exist along public/private scope boundaries
(e.g., between com and example.com), they are not required at these
boundaries, nor are scope boundaries required at zone cuts. In this
document public/private scope is considered independent of
administrative boundaries defined by the DNS (i.e., zone cuts).
The most well-known delineator of public/private scope is the Public
Suffix List (PSL) [PSL], which is described later in this document.
2.2.1. Public/private Boundaries
If we consider the root domain name itself to be public, then between
the root domain name and any private domain name (below), there must
exist at least one boundary going from some public parent to private
child. The first such boundary encountered upon downward traversal
from the root is the first-level public boundary. Subsequent public-
to-private boundaries are referred to as lower-level public
boundaries. For example, because the com domain name is considered
public, if we assume that example.com is private, then the first-
level public boundary is between com and example.com. If the
public.example.com domain name is considered public (i.e., children
domain names can be registered by arbitrary third parties) and
foo.public.example.com is a private domain name, then a lower-level
public boundary exists between public.example.com and
foo.public.example.com.
2.3. Domain Name Relationships
In this document two types of domain name relationships are
identified: ancestry and policy. An ancestral relationship exists
between two domains if one domain name is an ancestor of the other.
Deccio & Levine Expires January 7, 2016 [Page 4]
Internet-Draft Concepts for Domain Name Relationships July 2015
A policy relationship exists between two domain names if their
relationship is such that application policy should treat them as
equivalent. For example, the two names might be administered by the
operating organization, or there might business or other
relationships between the two operating entities.
In the simplest case, two domain names might be policy-related for
all applications or purposes. However, it is possible that two
domains are related only for explicitly defined purposes.
An ancestral relationship between two names can be identified merely
by comparing the names themselves to determine whether one is a
substring of the other. However, there is no inherent way to
determine policy relationships neither by examination of the names
themselves, nor by examining the administrative boundaries (i.e.,
zone cuts) defined in the DNS. This is the problem being considered
in this document.
3. Policy-based Domain Name Relationships
Because policy-based domain name relationships are not inherently
apparent based on the names themselves or DNS protocol, mechanisms
outside the DNS namespace and base protocol are necessary to
advertise and detect those relationships.
In this section we enumerate the different types of ancestral and
scope relationships upon which policy-based relationships can be
overlaid.
3.1. Cross-Scope Policy Relationships
If scope of one domain name is public and another is private, then it
can be inferred, by the definition of their respective scopes, that
there exists no policy-based relationship between the two. That is,
a public domain name cannot be related, for policy purposes, to a
private domain name.
Note that this doesn't prohibit policy relationships between two
domain names of the same scope but having (an even number) of scope
boundaries in between.
3.2. Intra-Scope Policy Relationships
We now consider the existence of a policy relationship between two
domains names of the same scope.
Deccio & Levine Expires January 7, 2016 [Page 5]
Internet-Draft Concepts for Domain Name Relationships July 2015
3.2.1. Public-public Policy Relationships
The connotation of a public domain name in the context of policy is
that it should not be used for purposes normally associated with
private domain names. For example, it would be unreasonable to
expect legitimate mail to come from an email address having the exact
suffix of org.au (a domain name currently identified by [PSL] as
being public). This is especially true of domain names above the
first-level public boundary.
Because of this connotation, one consideration for policy amongst two
domain names, both public, is that no effective relationship exists
because they are ineligible by definition. Other than that, there is
insufficient information from only domain names and scope alone to
confirm or deny a policy relationship.
3.2.2. Private-private Policy Relationships
There are two classes of potential private-private policy
relationships: ancestral and cross-domain (non-ancestral). In
neither case can the presence or absence of a policy relationship be
confirmed using only the names and scope information.
4. Known Applications Requiring Identification of Policy-based Domain
Relationships
In this section we discuss the current state of known applications
requiring identification of policy-based domain name relationships.
4.1. HTTP Cookies
Domain names are used extensively in conjunction with the Hypertext
Transfer Protocol (HTTP) ([RFC7230], [RFC7231]). The domain names
used in Uniform Resource Identifiers (URIs) [RFC3986] are used by
HTTP clients not only for resolution to an HTTP server Internet
Protocol (IP) address, but also for enforcing policy.
HTTP clients maintain local state in the form of key/value pairs
known as cookies ([RFC6265]). While most often cookies are initially
set by HTTP servers, HTTP clients send all cookies in HTTP requests
for which the domain name in the URI is within the cookies' scope.
The scope of a cookie is defined using a domain name in the "domain"
attribute of the cookie. When a cookie's "domain" attribute is
specified as a domain name (as opposed to an IP address), the domain
name in the URL is considered within scope if it is a descendant of
the "domain" attribute.
Deccio & Levine Expires January 7, 2016 [Page 6]
Internet-Draft Concepts for Domain Name Relationships July 2015
RFC 2965 [RFC2965] (now obsolete) required that the value of the
"domain" field carry at least one embedded dot. This was to prohibit
TLDs--which were almost exclusively public--from being associated, by
policy, with other domains. Cookies having public scope would enable
the association of HTTP requests across different, independently
operated domains, which policy association raises concerns of user
privacy and security.
In the current specification ([RFC6265]), the semantic requirements
were modified to match "public suffixes" because it was recognized
that TLDs are not the only domain names with public scope--and that
not all TLDs are public suffixes. The notion that all TLDs are
inherently public has been challenged by the many and diverse domain
names that have been delegated since 2013 as part of the new generic
top-level domain (gTLD) program ([NewgTLDs]).
4.2. Email sender verification
An emerging sender verification called Domain-based Message
Authentication, Reporting and Conformance (DMARC)
[I-D.kucherawy-dmarc-base] attempts to validate the domain name of
the author's address on the message's "From:" header using the
DomainKeys Identified Email (DKIM) [RFC5585] and Sender Policy
Framework (SPF) [RFC7208] authentication schemes. A DKIM signature
and SPF check each validate a specific domain name. For DKIM it is
the domain name corresponding the DKIM signature. For SPF the domain
name of the message's bounce address is validated. DMARC allows
approximate matching between the author's domain and the validated
domain name, where one can be an ancestor or descendant of the other.
DMARC validators are supposed to ensure that the two domain names are
under the same management, the specifics of which are deliberately
left out of the spec.
4.3. SSL certificate requests
Secure Socket Layer (SSL) certificate authorities typically validate
certificate signing requests by sending a confirmation message to one
of the WHOIS contacts for the (private scope) domain name (CA/B
Ballot 74 [CA/B-Ballot-74]). In cases where there are multiple
levels of delegation (i.e., crossing public/private scopes), the
WHOIS contact needs to be the one for the registrant of the domain,
not a higher level registration.
When an SSL certificate is for a wildcard domain name, the entire
range of names covered by the wildcard needs to be under the same
control. Authorities do not (knowingly) issue certificates for
public domain names such as *.org.au.
Deccio & Levine Expires January 7, 2016 [Page 7]
Internet-Draft Concepts for Domain Name Relationships July 2015
5. Public Suffix List
The most well-known resource currently available for identifying
public domain names is the Public Suffix List (PSL) [PSL]. The PSL
is explicitly referenced as an example of an up-to-date public suffix
list in [RFC6265]. The PSL was developed by Mozilla Firefox
developers to further address HTTP security and privacy concerns
surrounding cookie scope when the "no embedded dot" rule of [RFC2965]
was the upper limit.
The PSL contains a list of known public suffixes, and includes
placeholder public domains designated by "wildcard" notation in the
file. A wildcard implies that all children of the wildcard's parent
are in fact public domain names themselves--except where otherwise
noted as a wildcard exception. For example, we use the contrived
entries in Table 1 to demonstrate this use of the PSL.
+--------------+------------------------------------+
| Entry | Meaning |
+--------------+------------------------------------+
| example | example is public |
| *.example | All children of example are public |
| !foo.example | foo.example is private |
+--------------+------------------------------------+
Table 1: Contrived PSL Entries
These entries result in the scopes shown in Table 2:
+---------------------+---------+
| Name | Scope |
+---------------------+---------+
| example | Public |
| foo.example | Private |
| baz.foo.example | Private |
| bar.example | Public |
| baz.bar.example | Private |
| www.baz.bar.example | Private |
+---------------------+---------+
Domain name scope based on the PSL entries from Table 1.
Table 2: Contrived PSL Entries
The PSL effectively identifies scope, insomuch as the list is
accurate. Of the 6,823 entries in the PSL at the time of this
writing, all but 50 are used to designate first-level public
boundaries; the remainder designate lower-level boundaries. The
Deccio & Levine Expires January 7, 2016 [Page 8]
Internet-Draft Concepts for Domain Name Relationships July 2015
primary function of the PSL, therefore, is to delineate first-level
public boundaries.
Matters of policy that can be settled simply by identifying the scope
of the names in question are thus addressed by the PSL. However, the
question of determining whether a policy-based relationship between
intra-scope names (with the possible exception of those of public
scope) are unaddressed.
5.1. Known Application Usage
The PSL is used by several browsers, including Mozilla Firefox, to
identify domain names as public or private. This is used for
validating the domain attribute of cookies. Additionally, it
provides visual and organizational convenience for readily
identifying the highest intra-scope private ancestor for a given
private domain name (i.e., the child of the domain name's nearest
public ancestor). This is useful for organizing names and URIs by
domain name, as in bookmarks, and for highlighting key parts of URIs
or certificates in the address bar or other parts of the browser
interface.
Existing DMARC implementations are known to use the PSL to assert
policy-based relationships between SPF- or DKIM-authenticated
validated domain names and domain name corresponding to the address
in the "From:" header. Such a relationship is identified if two
domain names are both of private scope and share an ancestral
relationship.
DMARC implementations also use the PSL to identify the highest intra-
scope ancestor of a (private) domain name for the purpose of looking
up the DMARC DNS record. The the appropriate ancestor name is
identified it is appended to the label "_dmarc" to find the
appropriate information in the DNS.
SSL certificate authorities use the PSL to ensure that wildcards are
not issued for domain names having public scope.
6. Solution Considerations
The problem discussed in this document is the association of domain
names for policy purposes. The PSL has been the de-facto
supplementary resource utilized for identifying such relationships.
The shortcomings of only having domain names and their scope (e.g.,
via the PSL) have been treated in Section Section 5.
An alternate paradigm for addressing the problem involves a system
Deccio & Levine Expires January 7, 2016 [Page 9]
Internet-Draft Concepts for Domain Name Relationships July 2015
wherein policy-based relationships are explicitly defined on a per-
domain name (pair) basis. For scalability and dynamic response this
is most effectively achieved through defining these relationships in
the DNS itself, e.g., through special records included in the DNS at
(or near) the domain names themselves, such as the mechanism proposed
in [I-D.sullivan-domain-origin-assert]. One benefit to this paradigm
is that it allows the definition of policy-based relationships
between arbitrary names at any locations in the DNS domain name tree,
and the notion of scope becomes moot. Another benefit is that it
puts the definition of those relationships in the hands of the
administrators and operators of the domain names themselves, rather
than a third party.
There are several challenges with the domain name-centric paradigm as
well. One challenge is that it requires correct, consistent, and
coordinated efforts by affected domain name operators. The number of
involved parties, moving parts, and dependencies introduces more
chance for error. Additionally, having the information available
online (e.g., in the DNS) means that consumption by local
applications is dependent on real-time Internet connectivity, which
is not always possible nor desirable.
Another solution set is that which includes both a scope definition
resource (e.g., the PSL) and a mechanism for explicit definition of
policy-based relationships on a per-domain name basis. In this case
the scope definitions are consulted first to determine whether a
policy-based relationship is possible, after which (if necessary)
special domain name-specific lookups are issued to further determine
whether such a relationship exists. This addresses what might be the
most common issues using a central, relatively simple, and
established mechanism, leaving the flexibility for additional
extensibility with domain name-specific relationship definitions.
We recommend that the cost and the value of the different solution
paradigms be considered when developing solutions for the problem of
defining policy-based relationships between domain names. As part of
this, the model of domain name relationships outlined in Section
Section 2.3 should be analyzed to consider which types of
relationships are most in demand, and which solutions are sufficient
for the circumstances in highest demand. Such will enable an
appropriate and usable balance of efficiency, robustness,
flexibility, and autonomy.
7. IANA Considerations
This document includes no requests for IANA.
Deccio & Levine Expires January 7, 2016 [Page 10]
Internet-Draft Concepts for Domain Name Relationships July 2015
8. Security Considerations
This document does not specify a protocol or usage and, therefore,
there are no new security considerations for it. There are security
considerations for major cases in which domain boundaries are used,
such as HTTP Cookies and DMARC, both discussed here. See the
Security Considerations of RFC 6265 [RFC6265] and
[I-D.kucherawy-dmarc-base].
9. Informative References
[CA/B-Ballot-74]
Certificate Authority(CA)/Browser Forum, "Ballot 74",
2015, <https://cabforum.org/2012/05/31/
ballot-74-updates-to-domain-and-ip-validation-high-risk-
requests-and-data-source-in-the-baseline-requirements/>.
[I-D.kucherawy-dmarc-base]
Kucherawy, M. and E. Zwicky, "Domain-based Message
Authentication, Reporting and Conformance (DMARC)",
draft-kucherawy-dmarc-base-13 (work in progress),
February 2015.
[I-D.sullivan-domain-origin-assert]
Sullivan, A., "Asserting DNS Administrative Boundaries
Within DNS Zones", draft-sullivan-domain-origin-assert-02
(work in progress), October 2012.
[NewgTLDs]
ICANN, "New Generic Top-Level Domains", 2015,
<http://newgtlds.icann.org/>.
[PSL] Mozilla Foundation, "Public Suffix List", 2015,
<https://publicsuffix.org/>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
Identified Mail (DKIM) Service Overview", RFC 5585,
Deccio & Levine Expires January 7, 2016 [Page 11]
Internet-Draft Concepts for Domain Name Relationships July 2015
July 2009.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
April 2014.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230,
June 2014.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
Authors' Addresses
Casey Deccio
Verisign Labs
12061 Bluemont Way
Reston, VA 20190
USA
Phone: +1 703-948-3200
Email: cdeccio@verisign.com
John Levine
Taughannock Networks
PO Box 727
Trumansburg, NY 14886
Phone: +1 831 480 2300
Email: standards@taugh.com
URI: http://jl.ly
Deccio & Levine Expires January 7, 2016 [Page 12]
