-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-sullivan-dbound-problem-statement-00.txt
504 lines (334 loc) · 19.6 KB
/
draft-sullivan-dbound-problem-statement-00.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
IETF A. Sullivan
Internet-Draft Dyn, Inc.
Intended status: Standards Track J. Hodges
Expires: July 11, 2015 PayPal
J. Levine
Taughannock Networks
C. Deccio
Verisign
January 7, 2015
DBOUND: DNS Administrative Boundaries Problem Statement
draft-sullivan-dbound-problem-statement-00
Abstract
Some Internet client entities on the Internet make inferences about
the administrative relationships among services on the Internet based
on the domain names at which they are offered. At present, it is not
possible to ascertain organizational administrative boundaries in the
DNS, therefore such inferences can be erroneous in various ways.
Mitigation strategies deployed so far will not scale. The solution
offered in this memo is to provide a means to make explicit
assertions regarding the administrative relationships between 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 July 11, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Sullivan, et al. Expires July 11, 2015 [Page 1]
Internet-Draft Asserting DNS Boundaries January 2015
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.
Table of Contents
1. Prerequisites, Terminology, and Organization of this Memo . . 2
2. Introduction and Motivation . . . . . . . . . . . . . . . . . 2
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. Informative References . . . . . . . . . . . . . . . . . . . 6
Appendix A. Discussion Venue . . . . . . . . . . . . . . . . . . 8
Appendix B. Change History . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Prerequisites, Terminology, and Organization of this Memo
The reader is assumed to be familiar with the DNS ([RFC1034]
[RFC1035]) and the omain Name System Security Extensions (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].
To begin, Section 2 describes introduces the problem space and
motivations for this work. Then, Section 3 discusses the cases where
a there are needs for discerning administrative boundaries in the DNS
domain name space. [[TODO:Flesh out]]
2. Introduction and Motivation
Many Internet resources and services, especially at the application
layer, are identified primarily by DNS domain names [RFC1034]. As a
result, domain names have become fundamental elements in building
security policies and also in affecting user agent behaviour. For
example, domain names are used for defining the scope of HTTP state
management "cookies" [RFC6265].
Sullivan, et al. Expires July 11, 2015 [Page 2]
Internet-Draft Asserting DNS Boundaries January 2015
Another example is a user interface convention that purports to
display an "actual domain name" differently from other parts of a
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 actual domain name ends in "attackersite.tld", in the hope
of reducing user's potential impression of 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 domain names and X.509
certificates, see [RFC6125].
The simplest policy, and the one most likely to work, 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. Unfortunately, this approach is too naive to be
useful. Often, the real policy control is the same in several names
(in this example, example.org and its children). Therefore, clients
have attempted to make more sophisticated policies around some idea
of such shared control. We call such an area of shared control a
"policy realm", and the control held by the administrator the "policy
authority".
Historically, policies were sometimes based on the DNS tree. Early
policies made a firm distinction between top-level domains and
everything else; but this was also too naive, and later attempts were
based on inferences from the domain names themselves. That did not
work well, because there is no way in the DNS to discover the
boundaries of policy control around domain names.
Some have attempted to use the boundary of zone cuts (i.e. the
location of the zone's apex, which is at the SOA record; see
[RFC1034] and [RFC1035]). 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
administrative entity (like a company) might divide its domain up
into different zones for administrative reasons unrelated to the
names in that domain. It was also, prior to the advent of DNSSEC,
difficult to find zone cuts. Regardless, the location of a zone cut
is an administrative matter to do with the operation of the DNS
itself, and not useful for determining relationships among services
offered at names in the DNS.
These different issues often appear to be different kinds of
problems. The issue of whether two names may set cookies for one
Sullivan, et al. Expires July 11, 2015 [Page 3]
Internet-Draft Asserting DNS Boundaries January 2015
another appears to be a different matter from whether two names get
the same highlighting in a browser's address bar, or whether a
particular name "owns" all the names underneath it. But the problems
all boil down to the same fundamental problem, which is that of
determining whether two different names in the DNS are under the
control of the same entity and ought to be treated as having an
important administrative relationship to one another.
What appears to be needed is a mechanism to determine policy
boundaries in the DNS. That is, given two domain names, one needs to
be able to answer whether the first and the second are under the same
administrative control and same administrative policies. We may call
this state of affairs "being within the same policy realm". We may
suppose that, if this information were to be available, it would be
possible to make useful decisions based on the information.
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 or "effective TLDs". The term "public suffix" comes from a
site, [publicsuffix.org], that publishes a list of domains -- which
is also known as the "effective TLD (eTLD) list", and henceforth in
this specification as 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 policy realm as another, and
those that might be so treated. For instance, if "com" is on the
public suffix list, that means that "example.com" lies in a policy
realm distinct from that of com.
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 that are a
consequence of its structure (see [RFC1034] for background on that
structure). 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.
Sullivan, et al. Expires July 11, 2015 [Page 4]
Internet-Draft Asserting DNS Boundaries January 2015
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
they represent improvements on the fundamental mechanism of keeping
metadata about the DNS tree apart from the DNS tree itself.
3. Use Cases
In the most general sense, this memo presents a mechanism that can be
used either as a replacement of the public suffix list
[publicsuffix.org], or else as a way to build and maintain such a
list. The mechanism outlined here is explicitly restricted to names
having ancestor-descendant or sibling relationships, but only as a
practical matter; nothing about the mechanism makes that restriction
a requirement.
HTTP state management cookies The mechanism can be used to determine
the scope for data sharing of HTTP state management cookies
[RFC6265]. Using this mechansim, it is possible to determine
whether a service at one name may be permitted to set a cookie for
a service at a different name. (Other protocols use cookies, too,
and those approaches could benefit similarly.)
User interface indicators User interfaces sometimes attempt to
indicate the "real" domain name in a given domain name. A common
use is to highlight the portion of the domain name believed to be
the "real" name -- usually the rightmost three or four labels in a
domain name string.
Setting the document.domain property The DOM same-origin policy
might be helped by being able to identify a common policy realm.
Email authentication mechanisms Mail authentication mechanisms such
as DMARC [I-D.kucherawy-dmarc-base] need to be able to find policy
documents for a given domain name given a subdomain.
SSL and TLS certificates Certificate authorities need to be able to
discover delegation-centric domains in order to avoid issuance of
certificates at or above those domains.
HSTS and Public Key Pinning with includeSubDomains flag set
Linking domains together for reporting purposes
DMARC science fiction use case DMARC's current use of the PSL is to
determine the 'Organizational Domain'.. for use when discovering
DMARC policy records. PSL works well enough for production
Sullivan, et al. Expires July 11, 2015 [Page 5]
Internet-Draft Asserting DNS Boundaries January 2015
environments in today's world. However, after hearing about
cross-domain requirements of cookies and cross-domain security use
cases in the browser, it strikes me that any functionality (policy
authority?) that allows domains to be linked would be incredibly
useful in the DMARC world, too. DMARC?s requirement for
Identifier Alignment between SPF-authenticated domain, DKIM
d=domain, and a message?s From: domain could be relaxed to include
domains that were somehow associated via a policy authority. This
capability would be *very* nice to have at hand.
4. 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. In
general, assertions about another name should never be accepted
without querying the other name for agreement.
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.
5. IANA Considerations
IANA will be requested to register the SOPA RRTYPE if this proceeds.
6. Acknowledgements
TODO: update this
The authors thank Adam Barth, Dave Crocker, Brian Dickson, Phillip
Hallam-Baker, John Klensin, Murray Kucherawy, John Levine, Gervase
Markham, Patrick McManus, Henrik Nordstrom, Yngve N. Pettersen, Eric
Rescorla, Thomas Roessler, Peter Saint-Andre, and Maciej Stachowiak
for helpful comments.
7. Informative References
[I-D.kucherawy-dmarc-base]
Kucherawy, M., "Domain-based Message Authentication,
Reporting and Conformance (DMARC)", draft-kucherawy-dmarc-
base-00 (work in progress), March 2013.
Sullivan, et al. Expires July 11, 2015 [Page 6]
Internet-Draft Asserting DNS Boundaries January 2015
[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.
[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.
[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
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.
[publicsuffix.org]
Mozilla Foundation, "Public Suffix List", also known as:
Effective TLD (eTLD) List, .
https://publicsuffix.org/
Sullivan, et al. Expires July 11, 2015 [Page 7]
Internet-Draft Asserting DNS Boundaries January 2015
Appendix A. Discussion Venue
This Internet-Draft is discussed on the applications area working
group mailing list: [email protected].
Appendix B. Change History
[this section to be removed by RFC-Editor prior to publication as an
RFC]
This is a -00 Internet-draft, but borrows from various prior draft
works, listed below, as well as from discussions on the mailing list.
Andrew Sullivan, Jeff Hodges: Asserting DNS Administrative
Boundaries Within DNS Zones
http://tools.ietf.org/html/draft-sullivan-domain-policy-
authority-01
https://github.com/equalsJeffH/dbound/blob/master/draft-
sullivan-dbound-problem-statement-00.xml
John Levine: Publishing Organization Boundaries in the DNS
https://tools.ietf.org/html/draft-levine-orgboundary-02
https://github.com/equalsJeffH/dbound/blob/master/draft-levine-
orgboundary-02.txt
Casey Deccio, John Levine: Defining and Signaling
Relationships Between Domains
http://www.ietf.org/mail-archive/web/dbound/current/
pdfwad2AxxkYo.pdf
http://www.ietf.org/mail-archive/web/dbound/current/
msg00141.html
https://github.com/equalsJeffH/dbound/blob/master/deccio-
dbound-problem_statement-v3.pdf?raw=true
https://github.com/equalsJeffH/dbound/blob/master/deccio-
dbound-problem_statement-v3.txt
Sullivan, et al. Expires July 11, 2015 [Page 8]
Internet-Draft Asserting DNS Boundaries January 2015
Authors' Addresses
Andrew Sullivan
Dyn, Inc.
150 Dow St
Manchester, NH 03101
U.S.A.
Email: [email protected]
Jeff Hodges
PayPal
2211 North First Street
San Jose, California 95131
US
Email: [email protected]
John Levine
Taughannock Networks
PO Box 727
Trumansburg, NY 14886
Phone: +1 831 480 2300
Email: [email protected]
URI: http://jl.ly
Casey Deccio
Verisign
Email: [email protected]
Sullivan, et al. Expires July 11, 2015 [Page 9]