Network Working Group A. Sullivan Internet-Draft Dyn, Inc. Intended status: Informational May 4, 2012 Expires: November 5, 2012 Asserting Administrative Boundaries of Origin Using DNS Zones draft-sullivan-domain-origin-assert-00 Abstract Some clients on the Internet make inferences about the administrative relationships among servers on the Internet based on the domain names of those servers. Examples include decisions about acceptance of cookies and about cross-document information sharing in ECMAScript DOM. Perhaps unfortunately, real administrative boundaries in the DNS are not possible to detect, and therefore these inferences can go wrong in several ways. Mitigation strategies deployed so far will not scale. The solution to this is to provide a way to make an explicit assertion about the relationships between different domain names. 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 November 5, 2012. Copyright Notice Copyright (c) 2012 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 Sullivan Expires November 5, 2012 [Page 1] Internet-Draft Asserting origins May 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background and terminology . . . . . . . . . . . . . . . . . . 5 3. Overview of mechanism . . . . . . . . . . . . . . . . . . . . 5 3.1. Records in the DNS . . . . . . . . . . . . . . . . . . . . 5 3.2. Special target labels . . . . . . . . . . . . . . . . . . 6 3.2.1. Underscore target . . . . . . . . . . . . . . . . . . 6 3.2.2. Wildcards in targets . . . . . . . . . . . . . . . . . 6 3.3. Wire format of the BOUND Resource Record . . . . . . . . . 7 4. An example case . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Examples of using the BOUND record for determining boundaries . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.1. One delegation, eight administrative realms, no underscore target . . . . . . . . . . . . . . . . . . 8 4.1.2. One delegation, eight administrative realms, underscore targets . . . . . . . . . . . . . . . . . . 8 4.1.3. Two delegations, seven or eight administrative realms, underscore targets . . . . . . . . . . . . . . 9 5. Handling truncation . . . . . . . . . . . . . . . . . . . . . 10 6. Limitations of the approach . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Sullivan Expires November 5, 2012 [Page 2] Internet-Draft Asserting origins May 2012 1. Introduction Many network resources are accessed primarily by name. DNS names make up a fundamental part of the name by which people or other systems access those network resources. As a result, DNS names have become fundamental elements in building security policies and user agent behaviour. Some such policies attempt to determine the scope for data sharing of things like HTTP state management cookies [RFC6265] and cross-document information sharing in ECMAScript DOM. The idea is to foil the attempts of attackers in (for example) attackersite.co.tld from setting cookies for everyone in co.tld. Another use of the policy is a user interface convention that attempts to display the "real" domain name differently from other parts of the 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 name is inside "attackersite.tld", thereby hopefully reducing the user's impression that the user is 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 DNS names and X.509 certificates, see [RFC6125]. One way to build a reasonable policy 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. Such an approach can be awkward, however, when (as is often the case) the real administrative boundary is a shared one (in this example, example.org). Therefore, clients have attempted to make more sophisticated policies. Historically, some policies were based on the DNS tree. Early policies (for instance, in the earliest HTTP cookie specifications) just made a distinction between top-level domains and everything else; but this was too naive, and later attempts were based on inferences from the DNS names themselves. That did not work well, because there is no way in the DNS to discover the boundaries of administrative control around domain names. Some have attempted to use the boundary of zone cuts (i.e. the location of the zone's apex and SOA record; see [RFC1034] and [RFC1035]). Unfortunately, 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 Sullivan Expires November 5, 2012 [Page 3] Internet-Draft Asserting origins May 2012 administrative entity (like a company) might divide its domain up into different zones for administrative reasons unrelated to the purposes of sites named in that domain. It was also, prior to the advent of DNSSEC, difficult to find zone cuts. What appears to be needed is a mechanism to determine administrative boundaries in the DNS. That is, given two domain names, one needs to be able to answer whether the first name lies within the same administrative realm as the second. [[anchor2: I've used "administrative realm" here in an attempt to come up with yet another suitable term. "Administrative domain" is one other suggestion, though I fear a confusion between "administrative domain" and "domain" simpliciter, especially given that DNS operators are sometimes called domain administrators (so the domain is their administrative domain, of course, which is just confusing). Other thoughts on these terms welcome. --ajs@anvilwalrusden.com]] A particularly important distinction for security purposes is 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. The term "public suffix" comes from a site, publicsuffix.org, which publishes a list of domains (henceforth, 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 adminsitrative boundary, and those that may be so treated. 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, such as the empty non-terminal name. 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 [I-D.pettersen-subtld-structure]. It is unclear the extent to which those improvements would help, because Sullivan Expires November 5, 2012 [Page 4] Internet-Draft Asserting origins May 2012 they represent improvements on the fundamental mechansism of keeping metadata about the DNS tree apart from the DNS tree itself. 2. Background and terminology The reader is assumed to be familiar with the DNS ([RFC1034] [RFC1035]) and DNSSEC ([RFC4033] [RFC4034] [RFC4035] [RFC5155]). 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 [RFC2119]. 3. Overview of mechanism 3.1. Records in the DNS The basic mechanism uses resource records in the DNS to provide names through which the administrative boundary extends. The resource record is called BOUND (for administrative BOUNDary), RRTYPE TBD. [[anchor6: This could perhaps be a NAPTR or some such record with underscore conventions on the name, except that then I don't see how to make it extend well to underscore names themselves. Ideas? The disadvatage of a new RRTYPE is the reported difficulty of provisioning new RRs. --ajs@anvilwalrusden.com]] Each BOUND resource record contains in its RDATA either one fully- qualified domain name, or a domain name containing the wildcard character "*" in the leftmost label, or the special string "_"; for more on the latter two, see Section 3.2. There may be more than one BOUND resource record per name in the response. Each domain name in the RDATA is treated as a part of a common administrative realm as the owner name in the original QNAME. There are three possible responses to a query for the BOUND RRTYPE at an owner name that are relevant to determining the administrative realm. The first is Name Error (RCODE=3, also known as NXDOMAIN). In this case, the name itself does not exist, and no further processing is needed. The second is a No Data response [RFC2308] of any type. The No Data response means that the DNS named by the QNAME does not recognize any other name as part of a common administrative realm. The final is a response with one or more BOUND resource records in the Answer section. Each BOUND resource record asserts that the name Sullivan Expires November 5, 2012 [Page 5] Internet-Draft Asserting origins May 2012 identified in its RDATA shares the administrative realm of the owner name. The RDATA either contains a multi-label domain name relative to the root zone (see section 3.1 of [RFC1034]) or a string with some special characters in it (see Section 3.2. Any other response is no different from any other sort of response from the DNS, and is not in itself meaningful for determining the administrative realm of a name (though it might be meaningful for finding the BOUND record). 3.2. Special target labels 3.2.1. Underscore target A BOUND resource record with the single label "_" (called the "underscore target") is a positive assertion that no other domain name falls inside the administrative realm of the owner name. The record has a special use: it may be used to bootstrap operation. A client that has encountered the underscore target may remember the existence of the underscore target even after the expiry of the TTL on the resource record, until such time as a new query for the owner name may be made successfully. This rule permits implementations to cache positive statements of administrative isolation during disconnected periods, thereby starting a subsequent session with the values of prior affirmed policy. Apart from this bootstrapping use, and the ability of such an RR to have a TTL independent of the negative TTL value for the zone, this mechanism is semantically equivalent to a No Data answer. It would be absurd for the underscore target to exist with any other BOUND resource record at that owner name. An authoritative name server MAY refuse to serve a zone containing such an inconsistency, MAY refuse to load a zone containing such an inconsistency, or MAY suppress every BOUND RR at an owner name except that containing the underscore target. The name server side of a recursive resolver MAY discard every BOUND RR at an owner name except that containing the underscore target. Conforming servers MUST NOT serve the underscore target and any other BOUND RR at the same owner name. Clients receiving a BOUND RRset that includes the underscore target MUST accept that RR, and discard any other RR in the RRset. 3.2.2. Wildcards in targets The special character "*" is used to match any label, according to the wildcard label rules in section 4.3.3 of [RFC1034]. Sullivan Expires November 5, 2012 [Page 6] Internet-Draft Asserting origins May 2012 3.3. Wire format of the BOUND Resource Record [[anchor8: To be provided if we decide that the BOUND RR is the right thing to do. --ajs@anvilwalrusden.com]] 4. An example case For the purposes of discussion, it will be useful to imagine a portion of the DNS, using the domain example.tld. A diagram of the tree of this portion is in Figure 1. In the example, the domain example.tld includes several other names: www.example.tld, account.example.tld, cust1.example.tld, cust2.example.tld, test.example.tld, cust1.test.example.tld, and cust2.test.example.tld. tld | | ------example -- / / | \ \ / / | \ \ / www account \ cust2 test \ / \ cust1 cust1 cust2 Figure 1 In the example, the domain tld delegates the domain example.tld. There are other possible cut points in the example, and depending on whether the cuts exist there may be implications for the use of the examples. See Section 4.1, below. The (admittedly artificial) example permits us to distinguish a number of different roles. To begin with, there are three parties involved in the operation of services: o OperatorV, the operator of example.tld; o Operator1, the operator of cust1.example.tld; o Operator2, the operator of cust2.example.tld. Since there are three parties, there are likely three admininstrative boundaries as well; but the example contains some others. For instance, the names www.example.tld and example.tld are undoubtedly in the same administrative realm. By way of contrast, account.example.tld might be treated as completely separate, because OperatorV might wish to ensure that the accounts sytem is never permitted to share anything with any other name. By the same token, the names underneath test.example.tld are actually the test-instance Sullivan Expires November 5, 2012 [Page 7] Internet-Draft Asserting origins May 2012 sites for customers. So cust1.test.example.tld might be in the same administrative realm as cust1.example.tld, but test.example.tld is certainly not in the same administrative realm as www.example.tld. Finally, supposing that Operator1 and Operator2 merge their operations, it seems that it would be useful for cust1.example.tld and cust2.example.tld to lie in the same administrative realm, without including everything else in example.tld. 4.1. Examples of using the BOUND record for determining boundaries This section provides some examples of different configurations of the example tree in Section 4, above. The examples are not exhaustive, but may provide an indication of what might be done with the mechanism. 4.1.1. One delegation, eight administrative realms, no underscore target In this scenario, the example portion of the DNS name space contains all and only the following BOUND records: example.tld 86400 IN BOUND www.example.tld www.example.tld 86400 IN BOUND example.tld Tld is the top-level domain, and has delegated example.tld. The operator of example.tld makes no delegations. There are four operators involved: the operator of tld, the operator of example.tld, the operator of the services at cust1.example.tld and cust1.test.example.tld, and the operator of the services at cust2.example.tld and cust2.test.example.tld. In this arrangement, example.tld and www.example.tld positively claim to be within the same administrative realm. Every other name stands alone. A query for a BOUND record at any of those other names will result in a No Data response, which means that none of them include any other name in the same administrative realm. As a result, there are eight separate administrative realms in this case: tld, {example.tld and www.example.tld}, test.example.tld, cust1.test.example.tld, cust2.test.example.tld, account.example.tld, cust1.example.tld, and cust2.example.tld. 4.1.2. One delegation, eight administrative realms, underscore targets This example mostly works the same way as the one in Section Section 4.1.1, but there is a slight difference. In this case, both tld and test.example.tld publish underscore targets in their BOUND records: Sullivan Expires November 5, 2012 [Page 8] Internet-Draft Asserting origins May 2012 tld 86400 IN BOUND _ test.example.tld 86400 IN BOUND _ The practical effect of this is largely the same, except that these expressions of policy last 86,400 seconds instead of the length of time on the negative TTL in the relevant SOA for the zone. Many zones have short negative TTLs because of expectations that newly- added records will show up quickly. This mechanism permits such names to express their administrative isolation for predictable periods of time. Moreover, because clients are permitted to retain these records during periods when DNS service is not available, a client could go offline for several weeks, and return to service with the presumption that test.example.tld is still not in any administrative realm with any other name. 4.1.3. Two delegations, seven or eight administrative realms, underscore targets In this scenario, example.tld delegates the name test.example.tld. In this case, there is an SOA record for test.example.tld. The BOUND record at test.example.tld is maintained, however. At the same time, the Operator1 determines that it is safe to treat the test instance and production instance as being in the same adminsitrative realm. To begin with, Operator1 asks OperatorV to add the following record to the test.example.tld zone: cust1.test.example.tld 86400 IN BOUND cust1.example.tld This arrangement is not complete yet. Until a record is also added at cust1.example.tld, Operator1's intention is only half fulfilled. The service at cust1.test.example.tld treats cust1.example.tld as part of a common administrative realm, but the converse is not the case. [[anchor9: I can't decide whether there's anything useful in this configuration. Thoughts? --ajs@anvilwalrusden.com]] To complete the process, Operator1 asks OperatorV to add the following record to the example.tld zone: cust1.example.tld 86400 IN BOUND cust1.test.example.tld Once this is complete, both names treat the other as part of the same administrative realm. In the end, the example segment of the DNS expresses the following administrative realms: tld, {example.tld, www.example.tld}, test.example.tld, {cust1.test.example.tld, cust1.example.tld}, cust2.example.tld, account.example.tld, cust2.example.tld. Sullivan Expires November 5, 2012 [Page 9] Internet-Draft Asserting origins May 2012 5. Handling truncation It is possible to put enough BOUND records into a zone such that the resulting response will exceed DNS or UDP protocol limits. In such cases, a UDP DNS response will arrive with the TC (truncation) bit set. Am BOUND response with the TC bit must be queried again in order to retrieve a complete response, in order to ensure that there is no missing underscore target (see Section 3.2.1). 6. Limitations of the approach There are three significant problems with this proposal, all of which are related to using DNS to deliver the data. The first is that new DNS RRTYPEs are difficult to deploy. While adding a new RRTYPE is straightforward, many provisioning systems do not have the necessary support and some firewalls and other edge systems continue to filter RRTYPEs they do not know. The second is that it is difficult for an application to obtain data from the DNS. The TTL on an RRset, in particular, is usually not available to an application, even if the application uses the facilities of the operating system to deliver other parts of an unknown RRTYPE. Finally, in many environments the system hosting the application has only proxied access to the Internet, and cannot query the DNS directly. It is not clear how such clients could ever possibly retrieve the BOUND record for a name. 7. Security Considerations This mechanism enables publication of assertions about administrative relationships of different DNS-named systems on the Internet. If such assertions are 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. 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. 8. IANA Considerations IANA will be requested to register the BOUND RRTYPE if this proceeds. Sullivan Expires November 5, 2012 [Page 10] Internet-Draft Asserting origins May 2012 9. Acknowledgements The author thanks Dave Crocker, Jeff Hodges, Murray Kucherawy, Patrick McManus, Yngve N. Pettersen, and Peter St Andre for early discussion of this idea. 10. References 10.1. 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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. 10.2. Informative References [I-D.pettersen-subtld-structure] Pettersen, Y., "The Public Suffix Structure file format and its use for Cookie domain validation", draft-pettersen-subtld-structure-09 (work in progress), March 2012. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Sullivan Expires November 5, 2012 [Page 11] Internet-Draft Asserting origins May 2012 Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011. [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011. Author's Address Andrew Sullivan Dyn, Inc. 150 Dow St Manchester, NH 03101 U.S.A. Email: asullivan@dyn.com Sullivan Expires November 5, 2012 [Page 12]