Network Working Group A. Sullivan Internet-Draft Dyn, Inc. Intended status: Informational March 12, 2012 Expires: September 13, 2012 Asserting Administrative Policies and Boundaries in DNS Zones draft-sullivan-zone-policy-assertions-01 Abstract Some security policies on the Internet depend on the idea of the "domain policy" or "zone policy". It is difficult to discover such policies, and it is harder to do so in a way that does not subject operators of domains to others' assertions. This memo describes the problem, and proposes a mechanism for solving it. 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 September 13, 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 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. Sullivan Expires September 13, 2012 [Page 1] Internet-Draft Asserting Zone Policy March 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Example cases . . . . . . . . . . . . . . . . . . . . . . . 3 2. What is the Problem? . . . . . . . . . . . . . . . . . . . . . 3 3. An analogy with anti-abuse systems . . . . . . . . . . . . . . 4 4. The Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Resource Records . . . . . . . . . . . . . . . . . . . . . . . 5 6. Policy Document . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Administrative boundaries . . . . . . . . . . . . . . . . . 6 6.2. Unicode Repertoire . . . . . . . . . . . . . . . . . . . . 6 6.3. Alternative Names . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 9. Informative References . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Sullivan Expires September 13, 2012 [Page 2] Internet-Draft Asserting Zone Policy March 2012 1. Introduction [[anchor2: This document contains ideas that may have been the result of a visit from the bad idea fairy. It's still pretty sketchy. You have been warned. The document title is "zone" policy, and yet I've already convinced myself that it could be at any name, which sort of shows this isn't ready yet. --ajs@anvilwalrusden.com]] 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. Unfortunately, most of the attempts to build useful security policies around DNS names are based on rules of thumb that mostly work but that fail in ways surprising to users, to security system designers, or both. The failures are both too broad and too narrow: sometimes, failures prevent (or just make inconvenient) a desired use, while other times failures do not catch actual problems and permit things like cross-site scripting attacks. In general, the failures stem from a misunderstanding of what a domain name means, what a policy of "same origin" would look like, and what information the DNS can actually provide. 1.1. Example cases o The HTTP Cookies specification (formally known as "HTTP State Management Mechanism", [RFC6265]) depends on matching domain names and subdomains. o Some web browsers have adopted a list of "public" domain names that are known to be delegation-centric (the publicsuffix.org list). o Some web browsers use lists of officially-approved domain names near the DNS root to identify those where U-labels are to be displayed. If a name is not in the list, Internationalized Domain Names (IDNs) are displayed. (This is not based on the publicsuffix.org list, but the principle is the same.) o Many clients -- especially but not only web browsers -- use a "same origin" policy for following links to apparently related content. 2. What is the Problem? The use of domain names as a mechanism for identifying administrative boundaries is problematic for several reasons. Sullivan Expires September 13, 2012 [Page 3] Internet-Draft Asserting Zone Policy March 2012 1. The Start of Authority (SOA) Resource Record marks the boundary of a zone, but not the boundary of administrative control. For instance, the operator of example.com might delegate remoteoffice.example.com, inserting an SOA record at the apex of remoteoffice.example.com. For legal and organizational purposes, everything under example.com is one administrative domain. The remoteoffice.example.com delegation is only for administrative convenience. By the same token, a large zone might contain multiple domains that share a common SOA record, but that are actually completely separated for administrative purposes (this pattern of use is common in large corporations and academic institutions). 2. Even if the SOA record were a reliable indicator of organizational boundaries, in the absence of DNSSEC is it not convenient to find. 3. The publicsuffix.org list has no mechanism (apart from manual updates) to ensure it remains in sync with the actual delegation pattern on the Internet. It will not scale. 4. The publicsuffix.org list appears not to understand empty non- terminals. 5. IDN display policies that depend on the policies of domains near the root implicitly assume that IDN policies are transitive from parent to child. 6. Previous experiences with static lists of domain names maintained outside the DNS suggests that these mechanisms are fragile and hard to fix, particularly in the face of changes in the root zone. Scalability is a particular concern. As of this writing, ICANN has plans to delegate up to 1,000 new TLDs per year as long as there is demand. There is every reason to suppose that many of these will be IDNs, and that they will be aimed at communities that neither speak English nor even use Latin script, which means that volunteer- operated systems like publicsuffix.org will need a more diverse pool of volunteers. 3. An analogy with anti-abuse systems The e-mail world has already struggled with the problem of mail senders communicating their policies, and has come up with mechanisms that publish records in the DNS in order to communicate those policies. It seems that a similar approach might be useful for DNS systems themselves. In the e-mail technologies, the operator of a mail site publishes special records that are immediately below the name in question. For DNS zone operators' policies, this approach will not work, because at Sullivan Expires September 13, 2012 [Page 4] Internet-Draft Asserting Zone Policy March 2012 least sometimes zone cuts will stand in the way of the places where one might like to put such information. (In particular, where there are zone cuts and assertions about what happens on the other side of the cut, it is necessary to discover the policy on the other side is also.) Moreover, it is not clear that the sort of information that would be most helpful would fit nicely in a single DNS RR. Nevertheless, the basic mechanism of performing some DNS queries in order to find the relevant administrative policies provides a way of anchoring the policy in the very technology for which the policy is desired. That seems better than keeping such policies in a repository unlinked to the systems to which the policy applies. 4. The Mechanism The proposed mechanism includes two elements: 1. a DNS RR to identify the policy document and a policy server; 2. a policy document that includes all the relevant policies for the zone in question, where that zone is determined by its SOA RR. 5. Resource Records The operator of a zone that wishes to publish a policy document places a URI RR at the name _http._zpolicy at the location in the tree where the policy assertion is relevant. In most cases, this will be immediately below the zone apex. [[anchor3: This could be an SRV record instead, if we're worried about the novelty of URI --ajs@anvilwalrusden.com]] 6. Policy Document The operator of the zone provides, at the URIs in the _http._zpolicy RR, an XML document that provides the policy statements. The document has a time to live that permits applications to cache it and continue using it over time. The policy document may include statements about the administrative boundaries in the domain, the repertoire of Unicode characters that the zone permits in U-labels, and the names of domains that may be considered alternatives for the purposes of operation of a given protocol. Sullivan Expires September 13, 2012 [Page 5] Internet-Draft Asserting Zone Policy March 2012 6.1. Administrative boundaries It is possible to use the mechanism to assert things about other zones. For example, the policy document for example.com might make assertions about all names below example.com. But the operator of independent.example.com might not want to follow the same policy. In order to determine whether there is agreement about policies across zone cuts, a policy checking client examines the _http._zpolicy record on the parent side of a zone cut, in order to ensure that there is agreement about the administrative boundaries. Similarly, when a policy document asserts coverage of another domain (not necessarily subordinate, the policy checking agent always looks up the _http._zpolicy record in the other domain as well. In a subordinate domain, if the record does not exist, then the superordinate policy is in force. In a domain in another part of the DNS name space, if the value of the URI is the same, then the policy is the same. 6.2. Unicode Repertoire A policy may include a list of Unicode code points that are permitted characters in a U-label in that domain. Such a list may also include mechanisms for determining alternative names that either must or may be used whenever the first Unicode code point exists (this is a label generation policy in support of IDN code point variants). These mechanisms may be carried across zone cuts, but only with explicit inclusion in the subordinate zone's policy. In the absence of a policy, it may be assumed that the domain has no rules about Unicode code point inclusion. The existence of U-labels with code points outside the list should be taken as evidence of a failed policy. 6.3. Alternative Names Sometimes the same service is offered at more than one DNS name. For instance, the mail server at example.com and example.net might be the same, such that every localpart@example.com leads to the same mailbox as localpart@example.net. Clients might find it convenient to be able to discover these relationships, and it is not possible to do so in the DNS. A policy might include this data so that clients can discover it and so that servers may automatically configure themselves. In order for this to be safe, the tests in Section 6.1 need to be administered in order to ensure that one domain cannot make assertions about another domain. In the absence of any policy [[anchor4: Question: should this require that the policy cover the Sullivan Expires September 13, 2012 [Page 6] Internet-Draft Asserting Zone Policy March 2012 zone -- i.e. that it be at the apex? I used to think so, but I'm less convinced now. --ajs@anvilwalrusden.com]] 7. Security Considerations Discuss the need to check across cuts to ensure that both sides agree. 8. IANA Considerations The _zpolicy stuff needs to get registered. 9. Informative References [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 September 13, 2012 [Page 7]