idnits 2.17.1 draft-sullivan-domain-policy-authority-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 26 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 687 has weird spacing: '.../ www accou...' -- The document date (February 18, 2016) is 2987 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD1' is mentioned on line 363, but not defined == Outdated reference: A later version (-02) exists of draft-sullivan-dbound-problem-statement-01 -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF A. Sullivan 3 Internet-Draft Dyn, Inc. 4 Intended status: Standards Track J. Hodges 5 Expires: August 21, 2016 PayPal 6 February 18, 2016 8 Asserting DNS Administrative Boundaries Within DNS Zones 9 draft-sullivan-domain-policy-authority-02 11 Abstract 13 Some entities on the Internet make inferences about the 14 administrative relationships among Internet services based on the 15 domain names at which those services are offered. At present, it is 16 not possible to ascertain organizational administrative boundaries in 17 the DNS; therefore such inferences can be erroneous. Mitigation 18 strategies deployed so far will not scale. This memo provides a 19 means to make explicit assertions regarding certain kinds of 20 administrative relationships between domain names. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 21, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 57 1.1. Organization of This Memo . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Overview of Start Of Policy Authority (SOPA) . . . . . . . . 4 60 3.1. Identifying a Target Name for Policy 61 Authority . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. Where SOPA Works Well . . . . . . . . . . . . . . . . . . 7 64 4.2. Where SOPA Works Less Well . . . . . . . . . . . . . . . 8 65 5. The SOPA Resource Record . . . . . . . . . . . . . . . . . . 8 66 5.1. The Relation Field . . . . . . . . . . . . . . . . . . . 9 67 5.2. The Target Field . . . . . . . . . . . . . . . . . . . . 9 68 6. Expressing Different Policies with the SOPA RRTYPE . . . . . 10 69 6.1. The Exclusion Relation . . . . . . . . . . . . . . . . . 11 70 6.2. The Inclusion Relation . . . . . . . . . . . . . . . . . 11 71 6.3. Interpreting DNS Responses . . . . . . . . . . . . . . . 12 72 6.4. Wildcards in Targets . . . . . . . . . . . . . . . . . . 12 73 6.5. TTLs and SOPA RRs . . . . . . . . . . . . . . . . . . . . 14 74 7. What Can be Done With a SOPA RR . . . . . . . . . . . . . . . 14 75 7.1. Exclusion has Priority . . . . . . . . . . . . . . . . . 14 76 8. An Example Case . . . . . . . . . . . . . . . . . . . . . . . 15 77 8.1. Examples of Using the SOPA Record for Determining 78 Boundaries . . . . . . . . . . . . . . . . . . . . . . . 16 79 8.1.1. Declaring a Public Suffix . . . . . . . . . . . . . . 16 80 8.1.2. One Delegation, Eight Administrative 81 Realms, Wildcard Exclusions . . . . . . . . . . . . . 16 82 8.1.3. One Delegation, Eight Administrative 83 Realms, Exclusion Wildcards . . . . . . . . . . . . . 17 84 9. Limitations of the approach and other considerations . . . . 17 85 9.1. Handling truncation . . . . . . . . . . . . . . . . . . . 18 86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 11. Internationalization Considerations . . . . . . . . . . . . . 19 88 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 89 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 90 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 14.1. Normative References . . . . . . . . . . . . . . . . . . 19 92 14.2. Informative References . . . . . . . . . . . . . . . . . 19 93 Appendix A. Discussion Venue . . . . . . . . . . . . . . . . . . 22 94 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 22 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 97 1. Introduction and Motivation 99 Many Internet resources and services, especially at the application 100 layer, are identified primarily by domain names [RFC1034]. As a 101 result, domain names have become fundamental elements in building 102 security policies and also in affecting user agent behaviour. 103 Discussion of several of these uses, and some of the associated 104 issues can be found in [I-D.sullivan-dbound-problem-statement]. 106 Historically, attempts to build the security policies have relied on 107 the public suffix list (see discussion in 108 [I-D.sullivan-dbound-problem-statement]). We proceed from the view 109 that some uses of the public-suffix list never were going to achieve 110 their goal, and that the public/private distinction may be a poor 111 proxy for the kinds of relationships that are actually needed. At 112 the same time, it will be necessary to continue to use something like 113 a public suffix list for some important classes of behaviour (both to 114 achieve acceptable performance characteristics and to deal with 115 deployed software). Therefore, the proposal below does not attempt 116 to address all the issues in [I-D.sullivan-dbound-problem-statement], 117 but offers a way to solve one important class of problems -- the 118 "orphan type" policies. 120 1.1. Organization of This Memo 122 [[CREF1: I find this section awkward here. Ditch it? 123 --ajs@anvilwalrusden.com]] 125 Necessary terminology is established in Section 2. Section 3 126 provides an overview of what the mechanism is supposed to do. Then, 127 Section 4 discusses the conditions where the technique outlined here 128 may be useful, and notes some cases that the technique is not 129 intended solve. A definition of a new RRTYPE to support the 130 technique is in Section 5. There is some discussion of the use of 131 the RRTYPE in Section 6. Section 7 attempts to show how the 132 mechanism is generally useful. Then, Section 8 offers an example 133 portion of a DNS tree in an effort to illustrate how the mechanism 134 can be useful in certain example scenarios. Section 9 notes some 135 limitations of the mechanism. Section 10 outlines how the mechanism 136 might be used securely, and Section 11 addresses the 137 internationalization consequences of the SOPA record. Finally, 138 Section 12 includes the requests to IANA for registration. 140 2. Terminology 142 The reader is assumed to be familiar with the DNS ([RFC1034] 143 [RFC1035]) and the Domain Name System Security Extensions (DNSSEC) 144 ([RFC4033] [RFC4034] [RFC4035] [RFC5155]). A number of DNS terms can 145 be found in [RFC7719]. 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 The terms "policy realm" and "policy authority" are defined in 152 [I-D.sullivan-dbound-problem-statement]. For the purposes of 153 discussion here, it is important to remember that it is a matter of 154 fact as to whether two domains lie in the same policy realm. The 155 point of the mechanism here is not to create such facts, but merely 156 to expose them. The terms "inheritance type" and "orphan type" are 157 also defined in [I-D.sullivan-dbound-problem-statement]. The text 158 below attempts to apply the categories when they seem useful. 160 3. Overview of Start Of Policy Authority (SOPA) 162 When an application is attempting to make security decisions based on 163 domain names, it needs to answer questions about the relation between 164 those names. Suppose that the question to be answered is, "Given any 165 two domain names, do they lie in the same policy realm appropriate 166 for a given application?" In order to answer this, there are two 167 pieces of information needed: first, does the application need an 168 inheritance or orphan type of policy? Second do the two names lie in 169 the same policy realm? For orphan types of policy, the best way to 170 determine whether two names lie in the same policy realm is to look 171 for assertions about the two domain names. A good place to look for 172 assertions about domain names is in the DNS. 174 This memo presents a way to assert that two domains lie in the same 175 policy realm by placing a resource record (RR) at the affected domain 176 names in the DNS. The mechanism requires a new resource record type 177 (RRTYPE). It is called SOPA, for "Start Of Policy Authority" and 178 echoing the Start Of Authority or SOA record. While there are 179 reported difficulties in deploying new RRTYPEs, the only RRTYPE that 180 could be used to express all the necessary variables is the TXT 181 record, and it is unsuitable because it can also be used for other 182 purposes (so it needs to be covered itself). The use of this 183 mechanism does not require "underscore labels" to scope the 184 interpretation of the RR, in order to make it possible to use the 185 mechanism where the underscore label convention is already in use. 186 The SOPA RRTYPE is class-independent. 188 The use of SOPA records can do one of two things: it can confirm that 189 two names are in the same policy realm, or it can refute a claim that 190 they are. In order to learn whether a.long.example.com and 191 b.example.com are in the same policy realm, perform a DNS query for 192 the SOPA record for a.long.example.com. If the answer's RDATA 193 contains b.example.com, that is an assertion from the nameservers for 194 a.long.example.com that it is in the same policy realm as 195 b.example.com. Next, make a DNS query for the SOPA record for 196 b.example.com. If the answer's RDATA contains a.long.example.com, 197 then the two names are in the same policy realm. A positive policy 198 realm relationship ought to be symmetric: if example.com is in the 199 same policy realm as example.net, then example.net should be (it 200 would seem) in the same policy realm as example.com. In principle, 201 then, if a SOPA RR at a.long.example.com provides a target at 202 b.example.com, there should be a complementary SOPA RR at 203 b.example.com with a target of a.long.example.com. Because of the 204 distributed nature of the DNS, and because other DNS administrative 205 divisions need not be congruent to policy realms, the only way to 206 know whether two domain names are in the same policy realm is to 207 query at each domain name, and to correlate the responses. If any of 208 the forgoing conditions fails, then the two names are not in the same 209 policy realm. 211 [[CREF2: Something that could be useful here is a transitivity bit in 212 the SOPA record. That would allow SOPAs between a.example.com and 213 example.com, and b.example.com and example.com, to mean that 214 a.example.com and b.example.com are also in the same realm (but you 215 could shut it off by clearing the bit). I'm leery of this because of 216 the potential for abuse and also because I doubt it saves very much. 217 Might be useful for administrative saving, but it won't save lookups. 218 --ajs@anvilwalrusden.com]] 220 It is also possible for a SOPA record to contain the explicit 221 statement that other names do not lie in the same policy authority as 222 it. This negative assertion permits processing to stop. If the 223 assertion is about all other names, then the capability is 224 functionally equivalent to declaring a name to be a public suffix. 226 In operation where latency is an important consideration (such as in 227 a web browser), it is anticipated that the above correlations could 228 happen in advance of the user connection (that is, roughly the way 229 the existing public suffix list is compiled), and then additional 230 queries could be undertaken opportunistically. This would allow the 231 detection of changes in operational policy and make maintenance of 232 the installed list somewhat easier, but not require additional DNS 233 lookups while a user is waiting for interaction. 235 While many policies of the sort discussed in 236 [I-D.sullivan-dbound-problem-statement] appear to be based on domain 237 names, they are actually often only partly based on them. Often, 238 there are implicit rules that stem from associated components of 239 composite names such as URIs [RFC3986], e.g., the destination port 241 [RFC6335] or URI scheme [RFC4395] (or both). It is possible to make 242 those assumptions explicit, but at the cost of expressing in the 243 resulting resource record a tighter relationship between the DNS and 244 the services offered at domain names. SRV [RFC2782] records offer a 245 mechanism for expressing such relationships, and a SOPA record in 246 conjunction with an SRV record appears to provide the necessary 247 mechanism to express such relationships. (SRV records use underscore 248 labels, and this is an example of why underscore labels themselves 249 need to be coverable by SOPA records.) 251 3.1. Identifying a Target Name for Policy Authority 253 The RDATA of a SOPA RR contains a "target name" that either lies in 254 the same policy realm as the owner name of the RR, or that lies 255 outside of that policy realm. The SOPA record is therefore an 256 assertion, on the part of the authoritative DNS server for the given 257 owner name, that there is some policy relationship between the owner 258 name and the target name. If a given owner name lies in the same 259 policy realm as several other target names, an additional RR is 260 necessary for each such relationship, with one exception. It is not 261 uncommon for a name to have policy relationships with all the 262 children beneath it. Using the SOPA RR, it is possible to specify 263 that the policy target is all the names beneath a given owner name, 264 by using a wildcard target. 266 4. Use Cases 268 In the most general sense, this memo presents a mechanism that can be 269 used either as a replacement of the public suffix list 270 , or else as a way to build and maintain such a 271 list. Performance characteristics may make the mechanism impractical 272 as a full replacement, in which case a list will likely need to be 273 built and maintained. In the latter case, this mechanism is still 274 preferable because it aligns the policy assertions with the operation 275 of the domains themselves, and allows maintenance to be distributed 276 in much the way the operation of the DNS is (instead of being 277 centralized). 279 It is worth noting that the mechanism outlined here could be used for 280 names that are not along the same branch of the DNS tree (i.e. it 281 could permit the statement that the policy authority of 282 some.example.com and some.other.example.net is the same). Such uses 283 are unlikely to work in practice and probably should not be used for 284 general purposes. Most deployed code implicitly uses ancestor- 285 descendent relations as part of understanding the policy, and such 286 code will undoubtedly ignore cross-tree dependencies. [[CREF3: This 287 relaxes a restriction that was in previous versions, which officially 288 specified the use only for ancestor-descendent uses. It seems better 289 to make that a deployment consideration so that the restriction could 290 be relaxed in some circumstances where it would be appropriate. 291 --ajs@anvilwalrusden.com]] 293 By and large, the mechanism is best suited to "orphan" types of 294 policy. Where inheritance types of policy can use this, it is mostly 295 by treating the mechanism as a generator for public suffix 296 boundaries. 298 4.1. Where SOPA Works Well 300 HTTP state management cookies The mechanism can be used to determine 301 the scope for data sharing of HTTP state management cookies 302 [RFC6265]. Using this mechanism, it is possible to determine 303 whether a service at one name may be permitted to set a cookie for 304 a service at a different name. (Other protocols use cookies, too, 305 and those approaches could benefit similarly.) Because handling 306 of state management cookies often happens during user interaction, 307 this use case probably requires a cached copy of the relevant 308 list. In that case, the mechanism can be used to maintain the 309 list. 311 User interface indicators User interfaces sometimes attempt to 312 indicate the "real" domain name in a given domain name. A common 313 use is to highlight the portion of the domain name believed to be 314 the "real" name -- usually the rightmost three or four labels in a 315 domain name string. This has similar performance needs as HTTP 316 state management cookies. 318 Setting the document.domain property The DOM same-origin policy 319 might be helped by being able to identify a common policy realm. 320 This case again has a need for speedy determination of the 321 appropriate policy and would benefit from a cached list. It is 322 likely that the SOPA record on its own is inadequate for this 323 case, but the combination of SOPA and SRV records might be 324 helpful. 326 SSL and TLS certificates Certificate authorities need to be able to 327 discover delegation-centric domains in order to avoid issuance of 328 certificates at or above those domains. More generally, a CA 329 needs to decide whether, given a request, it should sign a 330 particular domain. This can be especially tricky in the case of 331 wildcards. 333 HSTS and Public Key Pinning with includeSubDomains flag 334 set 335 Clients that are using HSTS and public key pinning using 336 includeSubDomains need to be able to determine whether a subdomain 337 is properly within the policy realm of the parent. An application 338 performing this operation must answer the question, "Should I 339 accept the rules for using X as valid for Y.X?" This use case 340 sounds like an inheritance type, but it is in fact an orphan type. 342 Linking domains together for reporting purposes It can 343 be useful when preparing reports to be able to count different 344 domains as "the same thing". This is an example where special use 345 of SOPA even across the DNS tree could be helpful. 347 4.2. Where SOPA Works Less Well 349 Email authentication mechanisms Mail authentication mechanisms such 350 as DMARC [RFC7489] need to be able to find policy documents for a 351 domain name given a subdomain. This use case is an inheritance 352 type. Because the point of mechanisms like DMARC is to prevent 353 abuse, it is not possible to rely on the candidate owner name to 354 report accurately its policy relationships. But some ancestor is 355 possibly willing to make assertions about the policy under which 356 that ancestor permits names in the name space. This sort of case 357 can only use SOPA indirectly, via a static list that is composed 358 over time by SOPA queries. Other mechanisms will likely better 359 satisfy this need. 361 5. The SOPA Resource Record 363 The SOPA resource record, type number [TBD1], contains two fields in 364 its RDATA: 366 Relation: A one-octet field used to indicate the relationship 367 between the owner name and the target. 369 Target: A field used to contain a fully-qualified domain name 370 that is in some relationship with the owner name. This 371 field is a maximum of 255 octets long, to match the 372 possible length of a fully-qualified domain name. 374 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Relation | / 378 +-+-+-+-+-+-+-+-+ / 379 / Target / 380 / / 381 / / 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Figure 1 386 5.1. The Relation Field 388 The relation field is REQUIRED and contains an indicator of the 389 relationship between the owner name and the target name. This memo 390 specifies two possible values: 392 +-------+----------+------------------------------------------------+ 393 | Value | Setting | Meaning | 394 +-------+----------+------------------------------------------------+ 395 | 0 | Excluded | The target is not in the same policy realm as | 396 | | | the owner name | 397 | 1 | Included | The target is in the same policy realm as the | 398 | | | owner name | 399 +-------+----------+------------------------------------------------+ 401 Table 1 403 Additional values may be defined in future, according to the rules 404 set out in Section 12. 406 5.2. The Target Field 408 The target field contains a fully-qualified domain name, and is 409 REQUIRED to be populated. The name MUST be a domain name according 410 to the rules in [RFC1034] and [RFC1035], except that the any label of 411 the target MAY be the wildcard character ("*"; further discussion of 412 wildcards is in Section 6.4). The target MUST be sent in 413 uncompressed form [RFC1035], [RFC3597]. The target MUST NOT be an 414 alias [RFC2181], such as the owner name of a CNAME RR [RFC1034], 415 DNAME RR [RFC6672], or other similar such resource records. Note 416 that this is a fully-qualified domain name, so the trailing null 417 label is required. [[CREF4: This is a change from previous versions; 418 previously, the target was a root-relative domain name. So it's now 419 example.com. and used to be example.com (no trailing dot) when in 420 presentation format. The new form makes this a domain name, whereas 421 before it could really have been a text field. Not sure which is 422 better. --ajs@anvilwalrusden.com]] 424 The target name SHOULD be either an ancestor, a descendent, or a 425 sibling of the owner name in the record. This requirement is 426 intended to limit the applicability of the SOPA RR to names in the 427 same DNS hierarchy, thereby avoiding possible negative side effects 428 of unbounded linkages across disparate DNS subtrees, including those 429 subtrees rooted close to, or immediately below, the DNS root. In 430 special uses, however, it may be desirable to link across the DNS 431 tree. General-purpose clients MAY ignore target names that are 432 neither an ancestor, nor a descendent, nor a sibling of the owner 433 name in the record (and abort processing) in order to avoid the 434 aforementioned negative side-effects. 436 Targets MAY contain any series of octets, in order to accommodate 437 labels other than LDH labels [RFC6365]. No processing of labels 438 prior to matching targets is to be expected, however, and therefore 439 internationalized domain name targets use whatever form they appear 440 in the DNS. In particular, IDNA labels [RFC5890], [RFC5891], 441 [RFC5892], [RFC5893], [RFC5894] SHOULD appear in A-label form. A 442 SOPA-using client that receives a target containing octets outside 443 LDH MUST NOT treat the affected labels as U-labels, because there is 444 no way to discover whether the affected label is encoded as UTF-8 or 445 something else. 447 6. Expressing Different Policies with the SOPA RRTYPE 449 A SOPA RR has one of three different functions. The first is to 450 claim that two domain names are not in the same policy realm 451 ("exclusion"). The second is to claim that two domain names are in 452 the same policy realm ("inclusion"). In both of these cases, it is 453 possible to make the assertion over groups of DNS names. 455 The third function describes a portion of the tree that would be 456 covered by targets containing a wildcard, but where the policy is the 457 opposite of that expressed with the wildcard. This is expressed 458 simply by including the relevant specific exception. For example, 459 all the subdomains under example.com could be indicated in a target 460 "*.example.com". To express a different policy for 461 exception.example.com than for the rest of the names under 462 example.com requires two SOPA RRs, one with the target 463 "*.example.com" and the other with the target 464 "exception.example.com". The most-specific match to a target always 465 wins. 467 Is is important to note that the default setting is "exclusion". A 468 domain name does not lie in any other name's policy realm unless 469 there is an explicit statement by appropriate SOPA resource record(s) 470 to the contrary. If a candidate name does not appear in the target 471 of any SOPA record for some owner name, then that candidate target 472 does not lie in the same policy realm as that owner name. 474 It is acceptable for there to be more than one SOPA resource record 475 per owner name in a response. Each RR in the returned RRset is 476 treated as a separate policy statement about the original queried 477 name (QNAME). Note, however, that the QNAME might not be the owner 478 name of the SOPA RR: if the QNAME is an alias, then the actual SOPA 479 owner name in the DNS database will be different than the QNAME. In 480 other words, even though a SOPA target field is not allowed to be an 481 an alias, when resolving the SOPA RR aliases are followed; and SOPA 482 records are accepted transitively from the canonical name back to the 483 QNAME. 485 6.1. The Exclusion Relation 487 A SOPA record where the relation field has value 0 states that the 488 owner name and the target name are not in the same policy realm. 489 While this might seem useless (given the default of exclude), a SOPA 490 record with a relation field value of 0 can be useful in combination 491 with a long TTL field, in order to ensure long term caching of the 492 policy. 494 In addition, an important function of SOPA is to enable the explicit 495 assertion that no other name lies in the same policy realm as the 496 owner name (or, what is equivalent, that the owner name should be 497 treated as a public suffix). In order to achieve this, the operator 498 of the zone may use a wildcard target together with a relation field 499 value of 0. See Section 6.4. 501 In addition, an more-specific target can be used to override a more 502 general target (i.e. with a wildcard in the target) at the same owner 503 name. For example, 505 example.tld 86400 IN SOPA 0 *.example.tld 507 example.tld 86400 IN SOPA 1 www.example.tld 509 A SOPA-using client that receives a SOPA resource record with a 510 relation value of 0 MUST treat the owner name and the target name as 511 lying in different policy realms. 513 6.2. The Inclusion Relation 515 A SOPA record with a relation field set to 1 is an indicator that the 516 target name lies in the same policy realm as the owner name. In 517 order to limit the scope of security implications, the target name 518 and the owner name SHOULD stand in some ancestor-descendant or 519 sibling relationship to one another. A SOPA-using client that is not 520 prepared for inclusion relationships outside the same branch of the 521 DNS MAY ignore such relationships and treat them as though they did 522 not exist. 524 The left-most label of a target may be a wildcard record, in order to 525 indicate that all descendant or sibling names lie in the same policy 526 realm as the owner name. See Section 6.4. 528 A SOPA-using client that receives a SOPA resource record where 529 relation is set to 1 SHOULD treat the owner name and the target name 530 as lying in the same policy realm. If a client does not, it is 531 likely to experience unexpected failures because the client's policy 532 expectations are not aligned with those of the service operator. 534 6.3. Interpreting DNS Responses 536 There are three possible responses to a query for the SOPA RRTYPE at 537 an owner name that are relevant to determining the policy realm. The 538 first is Name Error (RCODE=3, also known as NXDOMAIN). In this case, 539 the owner name itself does not exist, and no further processing is 540 needed. 542 The second is a No Data response [RFC2308] of any type. The No Data 543 response means that the owner name in the QNAME does not recognize 544 any other name as part of a common policy realm. That is, a No Data 545 response is to be interpreted as though there were a SOPA resource 546 record with relation value 0 and a wildcard target. The TTL on the 547 policy in this case is the negative TTL from the SOA record, in case 548 it is available. 550 The final is a response with one or more SOPA resource records in the 551 Answer section. Each SOPA resource record asserts a relationship 552 between the owner name and the target name, according to the 553 functions of the SOPA RRTYPE outlined above. 555 Any other response is no different from any other sort of response 556 from the DNS, and is not in itself meaningful for determining the 557 policy realm of a name (though it might be meaningful for finding the 558 SOPA record). 560 6.4. Wildcards in Targets 562 The special character "*" in the target field is used to match any 563 label, but not according to the wildcard label rules in section 4.3.3 564 of [RFC1034]. Note that, because of the way wildcards work in the 565 DNS, is it not possible to place a restriction to the left of a 566 wildcard; so, for instance, example.*.example.com. does not work. In 567 a SOPA target, it is possible to place such a restriction. In such 568 use, a wildcard label matches exactly one label: 569 example.*.example.com. matches the target example.foo.example.com. 570 and example.bar.example.com., but not example.foo.bar.example.com. 571 To match the latter, it would be necessary also to include 572 example.*.*.example.com, which is also permitted in a target. This 573 use of the wildcard is consistent with the use in 574 . 576 If a SOPA target's first label is a wildcard label, the wildcard then 577 matches any number of labels. Therefore, a target of *.example.com. 578 matches both onelabel.example.com. and two.labels.example.com.; the 579 second match would not be a match in the DNS. This use of the 580 wildcard label does not match the public suffix list, but is included 581 for brevity of RRsets for certain presumed-common cases. This rule 582 is subject to more-specific matching (as discussed in Section 6.1 and 583 Section 6.2). To simplify implementation, more-specific matches 584 cannot have internal wildcards as described above. 586 The reason for these differences in wildcard-character handling is 587 because of the purpose of the wildcard character. In DNS matching, 588 processing happens label by label proceeding down the tree, and the 589 goal is to find a match. But in the case of SOPA, the candidate 590 match is presumed available, because the application would not 591 perform a SOPA look up if there were not a different target domain at 592 hand. Therefore, strict conformance with the DNS semantics of the 593 wildcard is not necessary. It is useful to be able to express 594 potential matches as briefly as possible, to keep DNS response sizes 595 small. 597 Multiple leading wildcard labels (e.g. *.*.example.com.) is an error. 598 An authoritative name server SHOULD NOT serve a SOPA RR with 599 erroneous wildcards when it is possible to suppress them, and clients 600 receiving such a SOPA RR MUST discard the RR. If the discarded RR is 601 the last RR in the answer section of the response, then the response 602 is treated as a No Data response. 604 It is possible for the wildcard label to be the only label in the 605 target name. In this case, the target is "every name". This makes 606 it trivial for an owner name to assert that there are no other names 607 in its policy realm. 609 Because it would be absurd for there to be more than one SOPA RR with 610 the same target (including wildcard target) in a SOPA RRset, a server 611 encountering more than one such target SHOULD only serve the RR for 612 the exclusion relation, discarding others when possible. Discarding 613 other RRs in the RRset is not possible when serving a signed RRset. 614 A client receiving multiple wildcard targets in the RRset MUST use 615 only the RR with relation set to 0. 617 As already noted, when a SOPA RR with a wildcard target appears in 618 the same RRset as a SOPA RR with a target that would be covered by 619 the wildcard, the specific (non-wildcard) RR expresses the policy for 620 that specific owner name/target pair. This way, exceptions to a 621 generic policy can be expressed. 623 6.5. TTLs and SOPA RRs 625 The TTL field in the DNS is used to indicate the period (in seconds) 626 during which an RRset may be cached after first encountering it (see 627 [RFC1034]). As is noted in Section 4, however, SOPA RRs could be 628 used to build something like the public suffix list, and that list 629 would later be used by clients that might not themselves have access 630 to SOPA DNS RRsets. In order to support that use as reliably as 631 possible, a SOPA RR MAY continue to be used even after the TTL on the 632 RRset has passed, until the next time that a SOPA RRset from the DNS 633 for the owner name (or a No Data response) is available. It is 634 preferable to fetch the more-current data in the DNS, and therefore 635 if such DNS responses are available, a SOPA-aware client SHOULD use 636 them. Note that the extension of the TTL when DNS records are not 637 available does not extend to the use of the negative TTL field from 638 No Data responses. 640 7. What Can be Done With a SOPA RR 642 Use of a SOPA RR enables a site administrator to assert or deny 643 relationships between names. By the same token, it permits a a 644 consuming client to detect these assertions and denials. 646 The use of SOPA RRs could either replace the public suffix list or 647 (often more likely due to some limitations -- see Section 9) simplify 648 and automate the management of the public suffix list. A client 649 could use the responses to SOPA queries to refine its determinations 650 about http cookie Domain attributes. In the absence of SOPA RRs at 651 both owner names, a client might treat a Domain attribute as though 652 it were omitted. More generally, SOPA RRs would permit additional 653 steps similar to steps 4 and 5 in [RFC6265]. 655 SOPA RRs might be valuable for certificate authorities when issuing 656 certificates, because it would allow them to check whether two names 657 are related in the way the party requesting the certificate claims 658 they are. 660 7.1. Exclusion has Priority 662 In order to minimize the chance of policy associations where none 663 exist, this memo always assumes exclusion unless there is an explicit 664 policy for inclusion. Therefore, a client processing SOPA records 665 can stop as soon as it encounters an exclusion record: if a parent 666 record excludes a child record, it makes no difference whether the 667 child includes the parent in the policy realm, and conversely. By 668 the same token, an inclusion SOPA record that specifies a target, 669 where the target does not publish a corresponding inclusion SOPA 670 record, is not effective. 672 8. An Example Case 674 For the purposes of discussion, it will be useful to imagine a 675 portion of the DNS, using the domain example.tld. A diagram of the 676 tree of this portion is in Figure 2. In the example, the domain 677 example.tld includes several other names: www.example.tld, 678 account.example.tld, cust1.example.tld, cust2.example.tld, 679 test.example.tld, cust1.test.example.tld, and cust2.test.example.tld. 681 tld 682 | 683 | 684 ------example ----- 685 / / | \ \ 686 / / | \ \ 687 / www account \ cust2 688 test \ 689 / \ cust1 690 cust1 cust2 692 Figure 2 694 In the example, the domain tld delegates the domain example.tld. 695 There are other possible cut points in the example, and depending on 696 whether the cuts exist there may be implications for the use of the 697 examples. See Section 8.1, below. 699 The (admittedly artificial) example permits us to distinguish a 700 number of different roles. To begin with, there are three parties 701 involved in the operation of services: 703 o OperatorV, the operator of example.tld; 705 o Operator1, the operator of cust1.example.tld; 707 o Operator2, the operator of cust2.example.tld. 709 Since there are three parties, there are likely three administrative 710 boundaries as well; but the example contains some others. For 711 instance, the names www.example.tld and example.tld are in this case 712 in the same policy realm. By way of contrast, account.example.tld 713 might be treated as completely separate, because OperatorV might wish 714 to ensure that the accounts system is never permitted to share 715 anything with any other name. By the same token, the names 716 underneath test.example.tld are actually the test-instance sites for 717 customers. So cust1.test.example.tld might be in the same policy 718 realm as cust1.example.tld, but test.example.tld is certainly not in 719 the same administrative realm as www.example.tld. 721 Finally, supposing that Operator1 and Operator2 merge their 722 operations, it seems that it would be useful for cust1.example.tld 723 and cust2.example.tld to lie in the same policy realm, without 724 including everything else in example.tld. 726 8.1. Examples of Using the SOPA Record for Determining Boundaries 728 This section provides some examples of different configurations of 729 the example tree in Section 8, above. The examples are not 730 exhaustive, but may provide an indication of what might be done with 731 the mechanism. 733 8.1.1. Declaring a Public Suffix 735 Perhaps the most important function of the SOPA RR is to identify 736 public suffixes. In this example, the operator of TLD publishes a 737 single SOPA record: 739 tld. 86400 IN SOPA 0 *. 741 8.1.2. One Delegation, Eight Administrative Realms, Wildcard Exclusions 743 In this scenario, the example portion of the domain name space 744 contains all and only the following SOPA records: 746 example.tld. 86400 IN SOPA 1 www.example.tld. 748 www.example.tld. 86400 IN SOPA 1 example.tld. 750 Tld is the top-level domain, and has delegated example.tld. The 751 operator of example.tld makes no delegations. There are four 752 operators involved: the operator of tld; OperatorV; Operator1, the 753 operator of the services at cust1.example.tld and 754 cust1.test.example.tld; and Operator2, the operator of the services 755 at cust2.example.tld and cust2.test.example.tld. 757 In this arrangement, example.tld and www.example.tld positively claim 758 to be within the same policy realm. Every other name stands alone. 759 A query for an SOPA record at any of those other names will result in 760 a No Data response, which means that none of them include any other 761 name in the same policy realm. As a result, there are eight separate 762 policy realms in this case: tld, {example.tld and www.example.tld}, 763 test.example.tld, cust1.test.example.tld, cust2.test.example.tld, 764 account.example.tld, cust1.example.tld, and cust2.example.tld. 766 8.1.3. One Delegation, Eight Administrative Realms, Exclusion Wildcards 768 This example mostly works the same way as the one in 769 Section Section 8.1.2, but there is a slight difference. In this 770 case, in addition to the records listed in Section 8.1.2, both tld 771 and test.example.tld publish exclusion of all names in their SOPA 772 records: 774 tld. 86400 IN SOPA 0 *. 776 test.example.tld. 86400 IN SOPA 0 *. 778 The practical effect of this is largely the same as the previous 779 example, except that these expressions of policy last (at least) 780 86,400 seconds instead of the length of time on the negative TTL in 781 the relevant SOA for the zone. Many zones have short negative TTLs 782 because of expectations that newly-added records will show up 783 quickly. This mechanism permits such names to express their 784 administrative isolation for predictable minimum periods of time. In 785 addition, because clients are permitted to retain these records 786 during periods when DNS service is not available, a client could go 787 offline for several weeks, and return to service with the presumption 788 that test.example.tld is still not in any policy realm with any other 789 name. 791 9. Limitations of the approach and other considerations 793 There are four significant problems with this proposal, all of which 794 are related to using DNS to deliver the data. 796 The first is that new DNS RRTYPEs are difficult to deploy. While 797 adding a new RRTYPE is straightforward, many provisioning systems do 798 not have the necessary support and some firewalls and other edge 799 systems continue to filter RRTYPEs they do not know. This is yet 800 another reason why this mechanism is likely to be initially more 801 useful for constructing and maintaining the public suffix list than 802 for real-time queries. 804 The second is that it is difficult for an application to obtain data 805 from the DNS. The TTL on an RRset, in particular, is usually not 806 available to an application, even if the application uses the 807 facilities of the operating system to deliver other parts of an 808 unknown RRTYPE. 810 The third, which is mostly a consequence of the above two, is that 811 there is a significant barrier to adoption: until browsers have 812 mostly all implemented this, operations need to proceed as though 813 nobody has. But browsers will need to support two mechanisms for 814 some period of time if they are to implement this mechanism at all, 815 and they are unlikely to want to do that. This may mean that there 816 is no reason to implement, which also means no reason to deploy. 817 This is made worse because, to be safe, the mechanism really needs 818 DNSSEC, and performing DNSSEC validation at end points is still an 819 unusual thing to do. This limitation may not be as severe for use- 820 cases that are directed higher in the network (such as using this 821 mechanism as an automatic feed to keep the public suffix list 822 updated, or for the use of CAs when issuing certificates). This 823 limitation could be reduced by using SOPA records to maintain 824 something like the current public suffix list in an automatic 825 fashion. 827 Fourth, in many environments the system hosting the application has 828 only proxied access to the Internet, and cannot query the DNS 829 directly. It is not clear how such clients could ever possibly 830 retrieve the SOPA record for a name. 832 9.1. Handling truncation 834 It is possible to put enough SOPA records into a zone such that the 835 resulting response will exceed DNS or UDP protocol limits. In such 836 cases, a UDP DNS response will arrive with the TC (truncation) bit 837 set. A SOPA response with the TC bit must be queried again in order 838 to retrieve a complete response, generally using TCP. This increases 839 the cost of the query, increases the time to being able to use the 840 answer, and may not work at all in networks where administrators 841 mistakenly block port 53 using TCP. 843 10. Security Considerations 845 This mechanism enables publication of assertions about administrative 846 relationships of different DNS-named systems on the Internet. If 847 such assertions are accepted without checking that both sides agree 848 to the assertion, it would be possible for one site to become an 849 illegitimate source for data to be consumed in some other site. In 850 general, assertions about another name should never be accepted 851 without querying the other name for agreement. 853 Undertaking any of the inferences suggested in this draft without the 854 use of the DNS Security Extensions exposes the user to the 855 possibility of forged DNS responses. 857 11. Internationalization Considerations 859 There is some discussion of how to treat targets that appear to have 860 internationalized data in Section 5.2. Otherwise, this memo raises 861 no internationalization considerations. 863 12. IANA Considerations 865 IANA will be requested to register the SOPA RRTYPE if this proceeds. 867 IANA will be requested to create a SOPA relation registry if this 868 proceeds. The initial values are to be found in the table in 869 Section 5.1. Registration rules should require a high bar, because 870 it's a one-octet field. Maybe RFC required? 872 13. Acknowledgements 874 The authors thank Adam Barth, Dave Crocker, Brian Dickson, Phillip 875 Hallam-Baker, John Klensin, Murray Kucherawy, John Levine, Gervase 876 Markham, Patrick McManus, Henrik Nordstrom, Yngve N. Pettersen, Eric 877 Rescorla, Thomas Roessler, Peter Saint-Andre, and Maciej Stachowiak 878 for helpful comments. 880 14. References 882 14.1. Normative References 884 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 885 Requirement Levels", BCP 14, RFC 2119, 886 DOI 10.17487/RFC2119, March 1997, 887 . 889 14.2. Informative References 891 [I-D.sullivan-dbound-problem-statement] 892 Sullivan, A., Hodges, J., and J. Levine, "DBOUND: DNS 893 Administrative Boundaries Problem Statement", draft- 894 sullivan-dbound-problem-statement-01 (work in progress), 895 July 2015. 897 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 898 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 899 . 901 [RFC1035] Mockapetris, P., "Domain names - implementation and 902 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 903 November 1987, . 905 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 906 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 907 . 909 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 910 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 911 . 913 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 914 specifying the location of services (DNS SRV)", RFC 2782, 915 DOI 10.17487/RFC2782, February 2000, 916 . 918 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 919 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 920 2003, . 922 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 923 Resource Identifier (URI): Generic Syntax", STD 66, 924 RFC 3986, DOI 10.17487/RFC3986, January 2005, 925 . 927 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 928 Rose, "DNS Security Introduction and Requirements", 929 RFC 4033, DOI 10.17487/RFC4033, March 2005, 930 . 932 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 933 Rose, "Resource Records for the DNS Security Extensions", 934 RFC 4034, DOI 10.17487/RFC4034, March 2005, 935 . 937 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 938 Rose, "Protocol Modifications for the DNS Security 939 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 940 . 942 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 943 Registration Procedures for New URI Schemes", RFC 4395, 944 DOI 10.17487/RFC4395, February 2006, 945 . 947 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 948 Security (DNSSEC) Hashed Authenticated Denial of 949 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 950 . 952 [RFC5890] Klensin, J., "Internationalized Domain Names for 953 Applications (IDNA): Definitions and Document Framework", 954 RFC 5890, DOI 10.17487/RFC5890, August 2010, 955 . 957 [RFC5891] Klensin, J., "Internationalized Domain Names in 958 Applications (IDNA): Protocol", RFC 5891, 959 DOI 10.17487/RFC5891, August 2010, 960 . 962 [RFC5892] Faltstrom, P., Ed., "The Unicode Code Points and 963 Internationalized Domain Names for Applications (IDNA)", 964 RFC 5892, DOI 10.17487/RFC5892, August 2010, 965 . 967 [RFC5893] Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts 968 for Internationalized Domain Names for Applications 969 (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010, 970 . 972 [RFC5894] Klensin, J., "Internationalized Domain Names for 973 Applications (IDNA): Background, Explanation, and 974 Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010, 975 . 977 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 978 DOI 10.17487/RFC6265, April 2011, 979 . 981 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 982 Cheshire, "Internet Assigned Numbers Authority (IANA) 983 Procedures for the Management of the Service Name and 984 Transport Protocol Port Number Registry", BCP 165, 985 RFC 6335, DOI 10.17487/RFC6335, August 2011, 986 . 988 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 989 Internationalization in the IETF", BCP 166, RFC 6365, 990 DOI 10.17487/RFC6365, September 2011, 991 . 993 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 994 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 995 . 997 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 998 Message Authentication, Reporting, and Conformance 999 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 1000 . 1002 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1003 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 1004 2015, . 1006 Appendix A. Discussion Venue 1008 This Internet-Draft is discussed in the dbound working group: 1009 dbound@ietf.org. 1011 Appendix B. Change History 1013 00 to 01: 1015 * Changed the mnemonic from BOUND to AREALM 1017 * Added ports and scheme to the RRTYPE 1019 * Added some motivating text and suggestions about what can be 1020 done with the new RRTYPE 1022 * Removed use of "origin" term, because it was confusing. The 1023 document filename preserves "origin" in the name in order that 1024 the tracker doesn't lose the change history, but that's just a 1025 vestige. 1027 * Removed references to cross-document information sharing and 1028 ECMAScript. I don't understand the issues there, but Maciej 1029 Stachowiak convinced me that they're different enough that this 1030 mechanism probably won't work. 1032 * Attempted to respond to all comments received. Thanks to the 1033 commenters; omissions and errors are mine. 1035 01 to 02: 1037 * Changed mnemonic again, from AREALM to SOPA. This in response 1038 to observation by John Klensin that anything using 1039 "administrative" risks confusion with the standard 1040 administrative boundary language of zone cuts. 1042 * Add discussion of two strategies: name-only or scheme-and-port. 1044 * Increase prominence of utility to CAs. This use emerged in 1045 last IETF meeting. 1047 02 to 03: 1049 * Removed discussion of scheme-and-port, which was confusing. 1051 * Add inclusion/exclusion/exception approach in response to 1052 comment by Phill H-B. 1054 * Change mechanism for indicating "no others" to a wildcard 1055 mechanism. 1057 * Added better discussion of use cases 1059 03 to 00: 1061 * Renamed file to get rid of "origin", which caused confusion. 1063 * Added Jeff as co-author 1065 * Remove exception relation; instead, more than one RR is 1066 allowed. 1068 * Added discussion of SRV records 1070 00 to 01: 1072 * Failed to include change control entry 1074 * Modest rearrangement of text, little improvement 1076 01 to 02: 1078 * Significant rearrangement of sections 1080 * Large removal of text (moved to problem statement document) 1082 * Considerably more detail in specification, including more 1083 rigorous description of RRTYPE 1085 * Altered handling of wildcard targets 1087 * Attempt to improve overview to make it plainer what the system 1088 does 1090 * Clarify what use cases really work 1091 * Reversion to permit cross-tree use, with deployment warnings 1092 that it won't be useful 1094 Authors' Addresses 1096 Andrew Sullivan 1097 Dyn, Inc. 1098 150 Dow St 1099 Manchester, NH 03101 1100 U.S.A. 1102 Email: asullivan@dyn.com 1104 Jeff Hodges 1105 PayPal 1106 2211 North First Street 1107 San Jose, California 95131 1108 US 1110 Email: Jeff.Hodges@PayPal.com