-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-sullivan-domain-policy-authority-01.txt
1120 lines (782 loc) · 47.4 KB
/
draft-sullivan-domain-policy-authority-01.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
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
IETF A. Sullivan
Internet-Draft Dyn, Inc.
Intended status: Standards Track J. Hodges
Expires: September 5, 2014 PayPal
March 4, 2014
Asserting DNS Administrative Boundaries Within DNS Zones
draft-sullivan-domain-policy-authority-01
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 September 5, 2014.
Copyright Notice
Copyright (c) 2014 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 & Hodges Expires September 5, 2014 [Page 1]
Internet-Draft Asserting DNS Boundaries March 2014
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 and Motivation . . . . . . . . . . . . . . . . . 2
2. Prerequisites, Terminology, and Organization of this Memo . . 5
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview of Start Of Policy Authority (SOPA) . . . . . . . . 6
4.1. Identifying a Target Name for Policy
Authority . . . . . . . . . . . . . . . . . . . . . . . . 7
5. The SOPA Resource Record . . . . . . . . . . . . . . . . . . 7
5.1. The Relation Field . . . . . . . . . . . . . . . . . . . 8
5.2. The Target Field . . . . . . . . . . . . . . . . . . . . 8
6. Expressing Different Policies with the SOPA RRTYPE . . . . . 9
6.1. The Exclusion Relation . . . . . . . . . . . . . . . . . 9
6.2. The Inclusion Relation . . . . . . . . . . . . . . . . . 10
6.3. Interpreting DNS Responses . . . . . . . . . . . . . . . 10
6.4. Wildcards in Targets . . . . . . . . . . . . . . . . . . 11
6.5. TTLs and SOPA RRs . . . . . . . . . . . . . . . . . . . . 12
7. What Can be Done With a SOPA RR . . . . . . . . . . . . . . . 12
7.1. Exclusion has Priority . . . . . . . . . . . . . . . . . 12
8. An Example Case . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Examples of Using the SOPA Record for Determining
Boundaries . . . . . . . . . . . . . . . . . . . . . . . 14
8.1.1. Declaring a Public Suffix . . . . . . . . . . . . . . 14
8.1.2. One Delegation, Eight Administrative
Realms, Wildcard Exclusions . . . . . . . . . . . . . 14
8.1.3. One Delegation, Eight Administrative
Realms, Exclusion Wildcards . . . . . . . . . . . . . 15
9. Limitations of the approach and other considerations . . . . 15
9.1. Handling truncation . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
13. Informative References . . . . . . . . . . . . . . . . . . . 17
Appendix A. Discussion Venue . . . . . . . . . . . . . . . . . . 19
Appendix B. Change History . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. 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
Sullivan & Hodges Expires September 5, 2014 [Page 2]
Internet-Draft Asserting DNS Boundaries March 2014
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].
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
Sullivan & Hodges Expires September 5, 2014 [Page 3]
Internet-Draft Asserting DNS Boundaries March 2014
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
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
Sullivan & Hodges Expires September 5, 2014 [Page 4]
Internet-Draft Asserting DNS Boundaries March 2014
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
they represent improvements on the fundamental mechanism of keeping
metadata about the DNS tree apart from the DNS tree itself.
2. 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 3 discusses the cases where this technique might be
useful. Section 4 describes the mechanism in general terms. A
definition of the new RRTYPE is in Section 5. There is some
discussion of the use of the RRTYPE is in Section 6. Section 7
attempts to show how the mechanism can address the use cases in
general terms. Then, Section 8 offers an example portion of a DNS
tree that can be used to understand the ways in which the mechanism
can be used to draw inferences about administrative relationships.
Section 9 notes some limitations of the mechanism. Section 10
outlines how the mechanism might be used securely.
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.
Sullivan & Hodges Expires September 5, 2014 [Page 5]
Internet-Draft Asserting DNS Boundaries March 2014
(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
4. Overview of Start Of Policy Authority (SOPA)
This memo presents a way to assert that two domains lie in the same
policy realm by placing a resource record (RR) at the domain names.
The mechanism requires a new resource record type (RRTYPE) to enable
these assertions, called SOPA (for "Start Of Policy Authority ,
echoing the Start Of Authority or SOA record). While there are
reported difficulties in deploying new RRTYPEs, the only RRTYPE that
could be used to express all the necessary variables is the TXT
record, and it is unsuitable because it can also be used for other
purposes. The use of this mechanism does not require "underscore
labels" to scope the interpretation of the RR, in order to make it
possible to use the mechanism where the underscore label convention
is already in use. The SOPA RRTYPE is class-independent.
While many policies of the sort discussed in Section 1 appear to be
based on domain names, they are actually often only partly based on
them. Often, there are implicit rules that stem from associated
components of composite names such as URIs [RFC3986], e.g., the
destination port [RFC6335] or URI scheme [RFC4395] (or both). It is
possible to make those assumptions explicit, but at the cost of
expressing in the resulting resource record a tighter relationship
between the DNS and the services offered at domain names. SRV
Sullivan & Hodges Expires September 5, 2014 [Page 6]
Internet-Draft Asserting DNS Boundaries March 2014
[RFC2782] records offer a mechanism for expressing such
relationships, and a SOPA record in conjunction with an SRV record
appears to provide the necessary mechanism to express such
relationships. (SRV records use underscore labels, and this is an
example of why underscore labels themselves need to be available for
SOPA records.)
It is worth observing that a positive policy realm relationship ought
to be symmetric: if example.com is in the same policy realm as
example.net, then example.net should be (it would seem) in the same
policy realm as example.com. In principle, then, if a SOPA RR at
a.example.com provides a target at b.example.com, there should be a
complementary SOPA RR at b.example.com with a target of
a.example.com. Because of the distributed nature of the DNS, and
because other DNS administrative divisions need not be congruent to
policy realms, the only way to know whether two domain names are in
the same policy realm is to query at each domain name, and to
correlate the responses.
4.1. Identifying a Target Name for Policy Authority
The RDATA of a SOPA RR contains a "target name", lying either in the
same policy realm as the owner name of the RR, that lies outside of
that policy realm. The SOPA record is therefore an assertion, on the
part of the authoritative DNS server for the given owner name, that
there is some policy relationship between the owner name and the
target name. If a given target name lies in the same policy realm as
several other target names, an additional RR is necessary for each
such relationship, with one exception. It is not uncommon for two
different names to have policy relationships among all the children
beneath them. Using the SOPA RR, it is possible to specify that the
policy target is all the names beneath a given owner name, by using a
wildcard target.
5. The SOPA Resource Record
The SOPA resource record, type number [TBD1], contains two fields in
its RDATA:
Relation: A one-octet field used to indicate the relationship
between the owner name and the target.
Target: A field used to contain a domain name, relative to the
root, that is in some relationship with the owner name.
Sullivan & Hodges Expires September 5, 2014 [Page 7]
Internet-Draft Asserting DNS Boundaries March 2014
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relation | /
+-+-+-+-+-+-+-+-+ /
/ Target /
/ /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
5.1. The Relation Field
The relation field is REQUIRED and contains an indicator of the
relationship between the owner name and the target name. This memo
specifies two possible values:
+-------+----------+------------------------------------------------+
| Value | Setting | Meaning |
+-------+----------+------------------------------------------------+
| 1 | Excluded | The target is not in the same policy realm as |
| | | the owner name |
| 2 | Included | The target is in the same policy realm as the |
| | | owner name |
+-------+----------+------------------------------------------------+
Table 1
5.2. The Target Field
The target field contains a (fully-qualified) domain name, and is
REQUIRED to be populated. The name MUST be a domain name according
to the rules in [RFC1034] and [RFC1035], except that the left-most
label of the target MAY be the wildcard character ("*"). The target
MUST be sent in uncompressed form [RFC1035] [RFC3597]. The target
MUST NOT be an alias [RFC2181], such as the owner name of a CNAME RR
[RFC1034], DNAME RR [RFC6672], or other similar such resource
records.
The target name MUST be either an ancestor, a descendent, or a
sibling of the owner name in the record. This requirement is
intended to limit the applicability of the SOPA RR to names in the
same DNS hierarchy, thereby avoiding possible negative side effects
of unbounded linkages across disparate DNS subtrees, including those
subtrees rooted close to, or immediately below, the DNS root.
Sullivan & Hodges Expires September 5, 2014 [Page 8]
Internet-Draft Asserting DNS Boundaries March 2014
6. Expressing Different Policies with the SOPA RRTYPE
A SOPA RR has one of three different functions. The first is to
claim that two domain names are not in the same policy realm
("exclusion"). The second is to claim that two domain names are in
the same policy realm ("inclusion"). In both of these cases, it is
possible to make the assertion over groups of DNS names.
The third function describes a portion of the tree that would be
covered by targets containing a wildcard, but where the policy is the
opposite of that expressed with the wildcard. This is expressed
simply by including the relevant specific exception. For example,
all the subdomains under example.com could be indicated in a target
"*.example.com". To express a different policy for
exception.example.com than for the rest of the names under
example.com requires two SOPA RRs, one with the target
"*.example.com" and he other with the target "exception.example.com".
The most-specific match to a target always wins.
Is is important to note that any given fully-qualified domain name
does not lie in any given other name's policy realm unless there is
an explicit statement by appropriate SOPA resource record(s) to the
contrary. If a candidate target name does not appear in the target
of any SOPA record for some owner name, then that candidate target
does not lie in the same policy realm as that owner name.
It is acceptable for there to be more than one SOPA resource record
per owner name in a response. Each domain name, in the RDATA of each
returned SOPA record, is treated as a separate policy statement about
the original QNAME (query name). Note, however, that the QNAME from
the query might not be the owner name of the SOPA RR: if the original
QNAME was an alias, then the actual SOPA owner name in the DNS
database will be different. In other words, even though a SOPA
target name is not allowed to be an an alias, statements about an
alias are followed and are accepted transitively from the alias to
the canonical name.
6.1. The Exclusion Relation
A SOPA record with a relation field with value 1 states that the
owner name and the target name are not in the same policy realm.
While this would seem not to be obviously useful (given that positive
declarations are required for two names to be in the same policy
realm), a SOPA record with a relation field value of 1 can be useful
in combination with a long TTL field, in order to ensure long term
caching of the policy.
Sullivan & Hodges Expires September 5, 2014 [Page 9]
Internet-Draft Asserting DNS Boundaries March 2014
In addition, an important function of SOPA is to enable the explicit
assertion that no other name lies in the same policy realm as the
owner name (or, what is equivalent, that the owner name should be
treated as a public suffix). In order to achieve this, the operator
of the zone may use a wildcard target together with a relation field
value of 1. See Section 6.4.
In addition, an exclusion relation can be used to override a more
general inclusion relation (i.e. with a wildcard in the target) at
the same owner name. For example,
example.tld 86400 IN SOPA 2 *.example.tld
www.example.tld 86400 IN SOPA 1 example.tld
A SOPA-using client that receives a SOPA resouce record with a
relation value of 1 MUST treat the owner name and the target name as
lying in different policy realms.
6.2. The Inclusion Relation
A SOPA record with a relation field set to 2 is an indicator that the
target name lies in the same policy realm as the owner name. In
order to limit the scope of security implications, the target name
and the owner name MUST stand in some ancestor-decendant or sibling
relationship to one another.
The left-most label of a target may be a wildcard record, in order to
indicate that all descendant or sibling names lie in the same policy
realm as the owner name. See Section 6.4.
A SOPA-using client that receives a SOPA resouce record where
relation is set to 2 SHOULD treat the owner name and the target name
as lying in the same policy realm. If a client does not, it is
likely to experience unexpected failures because the client's policy
expectations are not aligned with those of the service operator.
6.3. Interpreting DNS Responses
There are three possible responses to a query for the SOPA RRTYPE at
an owner name that are relevant to determining the policy realm. The
first is Name Error (RCODE=3, also known as NXDOMAIN). In this case,
the owner 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 owner name in the QNAME does not recognize
any other name as part of a common policy realm. That is, a No Data
Sullivan & Hodges Expires September 5, 2014 [Page 10]
Internet-Draft Asserting DNS Boundaries March 2014
response is to be interpreted as though there were a SOPA resource
record with relation value 1 and a wildcard target. The TTL on the
policy in this case is the negative TTL from the SOA record, in case
it is available.
The final is a response with one or more SOPA resource records in the
Answer section. Each SOPA resource record asserts a relationship
between the owner name and the target name, according to the
functions of the SOPA RRTYPE outlined above.
Any other response is no different from any other sort of response
from the DNS, and is not in itself meaningful for determining the
policy realm of a name (though it might be meaningful for finding the
SOPA record).
6.4. Wildcards in Targets
The special character "*" in the target field is used to match any
label, according to the wildcard label rules in section 4.3.3 of
[RFC1034]. Note that, because of the way wildcards work in the DNS,
is it not possible to place a restriction to the left of a wildcard;
so, for instance, example.*.example.com does not work. The effect is
maintained in this memo. An authoritative name server SHOULD NOT
serve a SOPA RR with erroneous wildcards when it is possible to
suppress them, and clients receiving such a SOPA RR MUST discard the
RR. If the discarded RR is the last RR in the answer section of the
response, then the response is treated as a No Data response.
It is possible for the wildcard label to be the only label in the
target name. In this case, the target is "every name". This makes
it trivial for an owner name to assert that there are no other names
in its policy realm.
Because it would be absurd for there to be more than one SOPA RR with
the same wildcard target in a SOPA RRset, a server encountering more
than one such wildcard target SHOULD only serve the RR for the
exclusion relation, discarding others when possible. Discarding
other RRs in the RRset is not possible when serving a signed RRset.
A client receiving multiple wildcard targets in the RRset MUST use
only the RR with relation set to 1.
When a SOPA RR with a wildcard target appears in the same RRset as a
SOPA RR with a target that would be covered by the wildcard, the
specific (non-wildcard) RR expresses the policy for that specific
owner name/target pair. This way, exceptions to a generic policy can
be expressed.
Sullivan & Hodges Expires September 5, 2014 [Page 11]
Internet-Draft Asserting DNS Boundaries March 2014
6.5. TTLs and SOPA RRs
The TTL field in the DNS is used to indicate the period (in seconds)
during which an RRset may be cached after first encountering it (see
[RFC1034]). As is noted in Section 3, however, SOPA RRs could be
used to build something like the public suffix list, and that list
would later be used by clients that might not themselves have access
to SOPA DNS RRsets. In order to support that use as reliably as
possible, a SOPA RR MAY continue to be used even after the TTL on the
RRset has passed, until the next time that a SOPA RRset from the DNS
for the owner name (or a No Data response) is available. It is
preferable to fetch the more-current data in the DNS, and therefore
if such DNS responses are available, a SOPA-aware client SHOULD use
them. Note that the extension of the TTL when DNS records are not
available does not extend to the use of the negative TTL field from
No Data responses.
7. What Can be Done With a SOPA RR
Use of a SOPA RR enables a site administrator to assert or deny
relationships between names. By the same token, it permits a a
consuming client to detect these assertions and denials.
The use of SOPA RRs could either replace the public suffix list or
(more likely due to some limitations -- see Section 9) simplify and
automate the management of the public suffix list. A client could
use the responses to SOPA queries to refine its determinations about
http cookie Domain attributes. In the absence of SOPA RRs at both
owner names, a client might treat a Domain attribute as though it
were omitted. More generally, SOPA RRs would permit additional steps
similar to steps 4 and 5 in [RFC6265].
SOPA RRs might be valuable for certificate authorities when issuing
certificates, because it would allow them to check whether two names
are related in the way the party requesting the certificate claims
they are.
7.1. Exclusion has Priority
In order to minimize the chance of policy associations where none
exist, this memo always assumes exclusion unless there is an explicit
policy for inclusion. Therefore, a client processing SOPA records
can stop as soon as it encounters an exclusion record: if a parent
record excludes a child record, it makes no difference whether the
child includes the parent in the policy realm, and conversely. By
the same token, an inclusion SOPA record that specifies a target,
where the target does not publish a corresponding inclusion SOPA
record, is not effective.
Sullivan & Hodges Expires September 5, 2014 [Page 12]
Internet-Draft Asserting DNS Boundaries March 2014
8. 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 2. 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 2
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 8.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 administrative
boundaries as well; but the example contains some others. For
instance, the names www.example.tld and example.tld are in this case
in the same policy realm. By way of contrast, account.example.tld
might be treated as completely separate, because OperatorV might wish
to ensure that the accounts system 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 sites for
customers. So cust1.test.example.tld might be in the same policy
realm as cust1.example.tld, but test.example.tld is certainly not in
the same administrative realm as www.example.tld.
Sullivan & Hodges Expires September 5, 2014 [Page 13]
Internet-Draft Asserting DNS Boundaries March 2014
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 policy realm, without
including everything else in example.tld.
8.1. Examples of Using the SOPA Record for Determining Boundaries
This section provides some examples of different configurations of
the example tree in Section 8, above. The examples are not
exhaustive, but may provide an indication of what might be done with
the mechanism.
8.1.1. Declaring a Public Suffix
Perhaps the most important function of the SOPA RR is to identify
public suffixes. In this example, the operator of TLD publishes a
single SOPA record:
tld. 86400 IN SOPA 1 *
8.1.2. One Delegation, Eight Administrative Realms, Wildcard Exclusions
In this scenario, the example portion of the domain name space
contains all and only the following SOPA records:
example.tld. 86400 IN SOPA 2 www.example.tld
www.example.tld. 86400 IN SOPA 2 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; OperatorV; Operator1, the
operator of the services at cust1.example.tld and
cust1.test.example.tld; and Operator2, 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 policy realm. Every other name stands alone.
A query for an SOPA 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 policy realm. As a result, there are eight separate
policy 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.
Sullivan & Hodges Expires September 5, 2014 [Page 14]
Internet-Draft Asserting DNS Boundaries March 2014
8.1.3. One Delegation, Eight Administrative Realms, Exclusion Wildcards
This example mostly works the same way as the one in
Section Section 8.1.2, but there is a slight difference. In this
case, in addition to the records listed in Section 8.1.2, both tld
and test.example.tld publish exclusion of all names in their SOPA
records:
tld. 86400 IN SOPA 1 *
test.example.tld. 86400 IN SOPA 1 *
The practical effect of this is largely the same as the previous
example, except that these expressions of policy last (at least)
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 minimum 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 policy realm with any other
name.
9. Limitations of the approach and other considerations
There are four 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. This is yet
another reason why this mechanism is likely to be initially more
useful for constructing and maintaining the public suffix list than
for real-time queries.
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.
The third, which is mostly a consequence of the above two, is that
there is a significant barrier to adoption: until browsers have
Sullivan & Hodges Expires September 5, 2014 [Page 15]
Internet-Draft Asserting DNS Boundaries March 2014
mostly all implemented this, operations need to proceed as though
nobody has. But browsers will need to support two mechanisms for
some period of time if they are to implement this mechanism at all,
and they are unlikely to want to do that. This may mean that there
is no reason to implement, which also means no reason to deploy.
This is made worse because, to be safe, the mechanism really needs
DNSSEC, and performing DNSSEC validation at end points is still an
unusual thing to do. This limitation may not be as severe for use-
cases that are directed higher in the network (such as using this
mechanism as an automatic feed to keep the public suffix list
updated, or for the use of CAs when issuing certificates). This
limitation could be reduced by using SOPA records to maintain
something like the current public suffix list in an automatic
fashion.
Fourth, 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 SOPA record for a name.
9.1. Handling truncation
It is possible to put enough SOPA 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. A SOPA response with the TC bit must be queried again in order
to retrieve a complete response, generally using TCP. This increases
the cost of the query, increases the time to being able to use the
answer, and may not work at all in networks where administrators
mistakenly block port 53 using TCP.
10. 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.
Sullivan & Hodges Expires September 5, 2014 [Page 16]
Internet-Draft Asserting DNS Boundaries March 2014
11. IANA Considerations
IANA will be requested to register the SOPA RRTYPE if this proceeds.
12. Acknowledgements
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.
13. 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.
[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.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
Sullivan & Hodges Expires September 5, 2014 [Page 17]
Internet-Draft Asserting DNS Boundaries March 2014
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[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.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35, RFC
4395, February 2006.
[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.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, RFC
6335, August 2011.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, June 2012.
[publicsuffix.org]
Mozilla Foundation, "Public Suffix List", also known as: