]> Dyn, Inc.

150 Dow St Manchester NH 03101 U.S.A. asullivan@dyn.com

PayPal

2211 North First Street San Jose California 95131 US Jeff.Hodges@KingsMountain.com

Taughannock Networks

PO Box 727 Trumansburg 14886 NY +1 831 480 2300 standards@taugh.com http://jl.ly

DBOUND Some Internet client entities on the Internet make inferences about the administrative relationships among services on the Internet based on the domain names at which they are offered. At present, it is not possible to ascertain organizational administrative boundaries in the DNS, therefore such inferences can be erroneous in various ways. Mitigation strategies deployed so far will not scale. This memo outlines what issues are to be addressed.

The reader is assumed to be familiar with the DNS ( ) and the Domain Name System Security Extensions (DNSSEC) ( ). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. To begin, describes introduces the problem space and motivations for this work. Then, discusses the cases where a there are needs for discerning administrative boundaries in the DNS domain name space.

Many Internet resources and services, especially at the application layer, are identified primarily by DNS domain names . As a result, domain names have become fundamental elements in building security policies and also in affecting user agent behaviour. For example, domain names are used for defining the scope of HTTP state management "cookies" . In addition there is a user interface convention that purports to display an "actual domain name" differently from other parts of a fully-qualified domain name, in an effort to decrease the success of phishing attacks. In this strategy, for instance, a domain name like "www.bank.example.com.attackersite.tld" is formatted to highlight that the actual domain name ends in "attackersite.tld", in the hope of reducing user's potential impression of visiting "www.bank.example.com". Issuers of X.509 certificates make judgements about administrative boundaries around domains when issuing the certificates. For some discussion of the relationship between domain names and X.509 certificates, see . We can call the interpretation of domain names for these security policies a domain-use rule. The simplest rule, and the one most likely to work, is to treat each different domain name distinctly. Under this approach, foo.example.org, bar.example.org, and baz.example.org are all just different domains. Unfortunately, this approach is too naive to be useful. Often, the real control over domain names is the same in several names (in this example, example.org and its children). Therefore, clients have attempted to make more sophisticated rules around some idea of such shared control. We call such an area of shared control a "policy realm", and the control held by the administrator of policy realm the "policy authority". Historically, rules were sometimes based on the DNS tree. Early rules made a firm distinction between top-level domains and everything else; but this was also too naive, and later attempts were based on inferences from the domain names themselves. That did not work well, because there is no way in the DNS to discover the boundaries of policy realms. Some have attempted to use the boundary of zone cuts (i.e. the location of the zone's apex, which is at the SOA record; see and ). That boundary is neither necessary nor sufficient for these purposes: it is possible for a large site to have many, administratively distinct subdomain-named sites without inserting an SOA record, and it is also possible that an administrative entity (like a company) might divide its domain up into different zones for administrative reasons unrelated to the names in that domain. It was also, prior to the advent of DNSSEC, difficult to find zone cuts. Regardless, the location of a zone cut is an administrative matter to do with the operation of the DNS itself, and not useful for determining relationships among policy realms. The different uses of domain names and their related issues often appear to be different kinds of problems. The issue of whether two names may set cookies for one another appears to be a different matter from whether two names get the same highlighting in a browser's address bar, or whether a particular name "owns" all the names underneath it. But the problems all boil down to the same fundamental problem, which is that of determining whether two different names in the DNS are under the control of the same entity and ought to be treated as having an important administrative relationship to one another. What appears to be needed is a mechanism to determine policy realm boundaries in the DNS. That is, given two domain names, one needs to be able to answer whether the first and the second are either within the same policy realm or have policy realms that are related in some way. We may suppose that, if this information were to be available, it would be possible to make useful decisions based on the information. A particularly important distinction for security purposes has been the one between names that are mostly used to contain other domains, as compared to those that are mostly used to operate services. The former are often "delegation-centric" domains, delegating parts of their name space to others, and are frequently called "public suffix" domains or "effective TLDs". The term "public suffix" comes from a site, , that publishes a list of domains -- which is also known as the "effective TLD (eTLD) list", and henceforth in this memo as the "public suffix list" -- that are used to contain other domains. Not all, but most, delegation-centric domains are public suffix domains; and not all public suffix domains need to do DNS delegation, although most of them do. The reason for the public suffix list is to make the distinction between names that must never be treated as being in the same policy realm as another, and those that might be so treated. For instance, if "com" is on the public suffix list, that means that "example.com" lies in a policy realm distinct from that of com. Unfortunately, the public suffix list has several inherent limitations. To begin with, it is a list that is separately maintained from the list of DNS delegations. As a result, the data in the public suffix list can diverge from the actual use of the DNS. Second, because its semantics are not the same as those of the DNS, it does not capture unusual features of the DNS that are a consequence of its structure (see for background on that structure). Third, as the size of the root zone grows, keeping the list both accurate and synchronized with the expanding services will become difficult and unreliable. Perhaps most importantly, it puts the power of assertion about the operational policies of a domain outside the control of the operators of that domain, and in the control of a third party possibly unrelated to those operators. There have been suggestions for improvements of the public suffix list, most notably in . It is unclear the extent to which those improvements would help, because they represent improvements on the fundamental mechanism of keeping metadata about the DNS tree apart from the DNS tree itself. Moreover, it is not entirely plain that the public/private distinction is really the best framework with which to understand the problem. It is plain that any solution that emerges will need, to be useful, to provide a way of making the public/private distinction, since so much deployed software relies on that distinction. It seems possible, however, that greater nuance would provide distinctions that are currently desired but cannot be supported using the public suffix list. The best way to figure this out is to enumerate known problems and see whether there is something common underlying them all, or whether the different problems might at least be grouped into a few common cases.

It is possible to identify two common policy patterns into which practical uses fall. One is a positive policy that will necessarily be imposed by an ancestor in case a policy for the owner name itself is not available. The other is a policy that need not get inherited from an ancestor. Negative assertions by an ancestor (i.e. that a descendent does not share a policy realm) fall into this category, because the descendent does not have a positive policy imposed. The first pattern we may call the inheritance type. In this use pattern, a client attempting to identify a policy that applies at a given name will use a policy found at a name closer to the root of the DNS, if need be. This approach is useful when a client must have some kind of policy in order to continue processing. Because the DNS is a hierarchical name system, it is always possible for a subordinate name to be permitted only in case the superordinate policies are followed. The second pattern we may call the orphan type. In this use pattern, if a policy at a name is not specifically offered then it is better to assume there is a null policy than to infer some inherited policy. Note that orphan names might be related to other names (which makes the term somewhat unfortunate). Rather, in these cases policy is assumed to be unshared unless there is evidence otherwise. Probably something better than "orphan" would be good, but I can't think of a better name. The choice of which pattern is preferable depends largely on what the use of a policy seeks to achieve. Some uses of policy require determination of commonality among domains; in such cases, the inheritance pattern may be needed. Other uses are attempts to identify differences between domains; in such cases, the orphan pattern is useful. The public suffix list provides a starting point for both patterns, but is neither necessary nor sufficient for either case. Where the inheritance pattern is used, the public suffix list provides a minimal starting point whence inheritance can start. Where the orphan pattern is used, the public suffix list provides the exclusion needed, but cannot provide either evidence that the list is up to date nor evidence that two owner names reside in the same policy realm.

This section outlines some questions and identifies some known use cases of the public suffix list. The mechanism can be used to determine the scope for data sharing of HTTP state management cookies . Using this mechanism, it is possible to determine whether a service at one name may be permitted to set a cookie for a service at a different name. (Other protocols use cookies, too, and those approaches could benefit similarly.) An application has to answer in this case the question, "Should I accept a cookie for domain X from the domain Y I am currently visiting?" User interfaces sometimes attempt to indicate the "real" domain name in a given domain name. A common use is to highlight the portion of the domain name believed to be the "real" name -- usually the rightmost three or four labels in a domain name string. An application has to answer in this case the question, "What domain name is relevant to show the user in this case?" The answer to this must be some portion of the domain name being displayed, but it is user- and context-sensitive. The DOM same-origin policy might be helped by being able to identify a common policy realm. An application has to answer in this case the question, "Is domain X under the same control as domain Y?" It's worth noting that, in this case, neither X nor Y need be actually visible to a user. Mail authentication mechanisms such as DMARC need to be able to find policy documents for a given domain name given a subdomain. An application performing DMARC processing must answer the question, "Given the domain X currently being evaluated, where in the DNS is the DMARC record?" DMARC depends on the DNS hierarchical relationship, and unlike some other cases wants to find the DMARC record that is closest to the root zone. Certificate authorities need to be able to discover delegation-centric domains in order to avoid issuance of certificates at or above those domains. There are two cases: A certificate authority must answer the question, "Should I sign a certificate at this domain name given the request before me?" A certificate authority must answer the question, "Should I sign a certificate for a wildcard at this domain name?" There is another case here, noted by Jeffrey Walton, about "verifying the end-entity certificate issued by an organizational subordinate CA *without* constraints." I didn't understand the issue well enough to write the text here. Clients that are using HSTS and public key pinning using includeSubDomains need to be able to determine whether a subdomain is properly within the policy realm of the parent. An application performing this operation must answer the question, "Should I accept the rules for using X as valid for Y.X?" It is frequently the case that domain names are aliases for one another. Sometimes this is because of an ongoing merger (as when one company takes over another and merges operations). A client encountering such a site needs to answer the question, "Is domain X just another name for domain Y?" An application that wants to categorize domains for the purposes of reporting must answer the question, "Are these two names versions of each other for the purposes of reporting statistics?" DMARC's current use of the PSL is to determine the 'Organizational Domain'.. for use when discovering DMARC policy records. PSL works well enough for production environments in today's world. However, after hearing about cross-domain requirements of cookies and cross-domain security use cases in the browser, it strikes me that any functionality (policy authority?) that allows domains to be linked would be incredibly useful in the DMARC world, too. DMARC?s requirement for Identifier Alignment between SPF-authenticated domain, DKIM d=domain, and a message?s From: domain could be relaxed to include domains that were somehow associated via a policy authority. This capability would be *very* nice to have at hand.

A mechanism that satisfied the needs outline above would enable publication of assertions about administrative relationships of different DNS-named systems on the Internet. If such assertions were to be accepted without checking that both sides agree to the assertion, it would be possible for one site to become an illegitimate source for data to be consumed in some other site. In general, positive assertions about another name should never be accepted without querying the other name for agreement. Undertaking any of the inferences suggested in this draft without the use of the DNS Security Extensions exposes the user to the possibility of forged DNS responses. This memo does not actually specify any mechanisms, so it raises no security considerations itself.

This memo makes no requests of IANA.

The authors thank Adam Barth, Dave Crocker, Casey Deccio, Brian Dickson, Jothan Frakes, Daniel Kahn Gillmor, Phillip Hallam-Baker, John Klensin, Murray Kucherawy, Gervase Markham, Patrick McManus, Henrik Nordstrom, Yngve N. Pettersen, Eric Rescorla, Thomas Roessler, Peter Saint-Andre, Maciej Stachowiak, and Jeffrey Walton for helpful comments or suggestions.

The email ecosystem currently lacks a cohesive mechanism through which email senders and receivers can make use of multiple authentication protocols in an attempt to establish reliable domain identifiers. This lack of cohesion prevents receivers from providing domain-specific feedback to senders regarding the accuracy of authentication deployments. Inaccurate authentication deployments preclude receivers from safely taking deterministic action against email that fails authentication checks. Finally, email senders do not have the ability to publish policies specifying actions that should be taken against email that fails multiple authentication checks. This memo presents a proposal for a scalable mechanism by which an organization can express, using the Domain Name System, domain-level policies and preferences for message validation, disposition, and reporting with predictable and accurate results. The enclosed proposal is not intended to introduce mechanisms that provide elevated delivery privilege of authenticated email. The proposal presents a mechanism for policy distribution that enables a continuum of increasingly strict handling of messages that fail multiple authentication checks, from no action, through silent reporting, up to message rejection. This document defines the term "Public Suffix domain" as meaning a domain under which multiple parties that are unaffiliated with the owner of the Public Suffix domain may register subdomains. Examples of Public Suffix domains include "org", "co.uk", "k12.wa.us" and "uk.com". It also defines a file format that can be used to distribute information about such Public Suffix domains to relying parties. As an example, this information is then used to limit which domains an Internet service can set HTTP cookies for, strengthening the rules already defined by the cookie specification. This specification updates RFC 6265 [RFC6265] by defining the term "Public Suffix domain". Information Sciences Institute (ISI) USC/ISI

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given.</t><t> This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.</t><t> This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK] Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK] This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK] Mozilla Foundation https://publicsuffix.org/

This Internet-Draft is discussed on the applications area working group mailing list: dbound@ietf.org.

[this section to be removed by RFC-Editor prior to publication as an RFC] Add questions from John Levine posting to mailing list. Initial version. This is a -00 Internet-draft, but borrows from various prior draft works, listed below, as well as from discussions on the mailing list. http://tools.ietf.org/html/draft-sullivan-domain-policy-authority-01 https://github.com/equalsJeffH/dbound/blob/master/draft-sullivan-dbound-problem-statement-00.xml https://tools.ietf.org/html/draft-levine-orgboundary-02 https://github.com/equalsJeffH/dbound/blob/master/draft-levine-orgboundary-02.txt http://www.ietf.org/mail-archive/web/dbound/current/pdfwad2AxxkYo.pdf http://www.ietf.org/mail-archive/web/dbound/current/msg00141.html https://github.com/equalsJeffH/dbound/blob/master/deccio-dbound-problem_statement-v3.pdf?raw=true https://github.com/equalsJeffH/dbound/blob/master/deccio-dbound-problem_statement-v3.txt