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]