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]