Network Working Group A. Sullivan Internet-Draft Dyn, Inc. Intended status: Informational March 5, 2012 Expires: September 6, 2012 Asserting Administrative Policies and Boundaries in DNS Zones draft-sullivan-zone-policy-assertions-00 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 6, 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 6, 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 4.1. Resource Records . . . . . . . . . . . . . . . . . . . . . 5 4.2. Policy Document . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. Administrative boundaries . . . . . . . . . . . . . . . 5 4.2.2. Unicode Repertoire . . . . . . . . . . . . . . . . . . 5 4.2.3. Alternative Names . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. Informative References . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Sullivan Expires September 6, 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 not really ready to read yet. You have been warned. --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 work from rules of thumb that mostly work but that fail in ways surprising to users. 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. 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 Sullivan Expires September 6, 2012 [Page 3] Internet-Draft Asserting Zone Policy March 2012 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. 2. 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. 3. The publicsuffix.org list appears not to understand empty non- terminals. 4. IDN display policies that depend on the policies of domains near the root implicitly assume that IDN policies are transitive from parent to child. 5. 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 do not 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 the DNS, this approach will not work, because at 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 Sullivan Expires September 6, 2012 [Page 4] Internet-Draft Asserting Zone Policy March 2012 repository unlinked to the systems to which the policy applies. 4. The Mechanism The proposed mechanism includes two elements: 1. a DNS RR just below the apex of a zone in order 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. 4.1. Resource Records The operator of a zone that wishes to publish a policy document places a URI RR at the name _http._zpolicy immediately below the apex of the zone. 4.2. 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 for zones, the repertoire of Unicode characters that the zone permits in U-labels, and the names of zones that may be considered alternatives for the purposes of operation of a given protocol. 4.2.1. Administrative boundaries [[anchor3: Here goes how the admin boundary works, how you have to check in more than one zone when the assertion works across zone cuts, and how you can short-circuit the lookup if the target of the URI record in one zone and another are the same thing. Default is "this zone only". --ajs@anvilwalrusden.com]] 4.2.2. Unicode Repertoire [[anchor4: Here goes how to express the repertoire permitted. Default "none". --ajs@anvilwalrusden.com]] 4.2.3. Alternative Names [[anchor5: Here goes how you put configuration information for a service here, in order to set up the same (e.g.) mail service on Sullivan Expires September 6, 2012 [Page 5] Internet-Draft Asserting Zone Policy March 2012 multiple domain names. Useful for "variants". Default "none". --ajs@anvilwalrusden.com]] 5. Security Considerations Discuss the need to check across cuts to ensure that both sides agree. 6. IANA Considerations The _zpolicy stuff needs to get registered. 7. 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 6, 2012 [Page 6]