idnits 2.17.1 draft-sullivan-domain-origin-assert-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 43 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 519 has weird spacing: '.../ www accou...' -- The document date (October 22, 2012) is 4198 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD1' is mentioned on line 340, but not defined == Outdated reference: A later version (-10) exists of draft-pettersen-subtld-structure-09 -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Sullivan 3 Internet-Draft Dyn, Inc. 4 Intended status: Informational October 22, 2012 5 Expires: April 25, 2013 7 Asserting DNS Administrative Boundaries Within DNS Zones 8 draft-sullivan-domain-origin-assert-02 10 Abstract 12 Some clients on the Internet make inferences about the administrative 13 relationships among servers on the Internet based on the domain names 14 of those servers. Perhaps unfortunately, it is not currently 15 possible to detect the real administrative boundaries in the DNS, and 16 therefore such inferences can go wrong in several ways. Mitigation 17 strategies deployed so far will not scale. The solution to this is 18 to provide a way to make an explicit assertion about the 19 relationships between different domain names and perhaps the services 20 provided at them. 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 April 25, 2013. 39 Copyright Notice 41 Copyright (c) 2012 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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Background, terminology, and organization of this memo . . . . 5 58 3. Overview of mechanism . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Identifying names as the scope for policy authority . . . 6 60 3.2. Identifying names, schemes, and ports as the scope for 61 policy authority . . . . . . . . . . . . . . . . . . . . . 6 62 4. The SOPA Resource Record . . . . . . . . . . . . . . . . . . . 7 63 4.1. Thr SOPA Resource Record only for names . . . . . . . . . 7 64 4.2. Thr SOPA Resource Record with ports and schemes . . . . . 8 65 5. Use of the SOPA RRTYPE . . . . . . . . . . . . . . . . . . . . 9 66 5.1. Special target labels . . . . . . . . . . . . . . . . . . 10 67 5.1.1. The root target . . . . . . . . . . . . . . . . . . . 10 68 5.1.2. Wildcards in targets . . . . . . . . . . . . . . . . . 10 69 5.2. What can be done with an SOPA RR . . . . . . . . . . . . . 11 70 6. An example case . . . . . . . . . . . . . . . . . . . . . . . 11 71 6.1. Examples of using the SOPA record for determining 72 boundaries . . . . . . . . . . . . . . . . . . . . . . . . 12 73 6.1.1. One delegation, eight administrative realms, no 74 root target . . . . . . . . . . . . . . . . . . . . . 13 75 6.1.2. One delegation, eight administrative realms, root 76 targets . . . . . . . . . . . . . . . . . . . . . . . 13 77 6.1.3. Two delegations, seven or eight policy realms, 78 root targets . . . . . . . . . . . . . . . . . . . . . 14 79 7. Limitations of the approach and other considerations . . . . . 15 80 7.1. Handling truncation . . . . . . . . . . . . . . . . . . . 16 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 87 Appendix A. Discussion Venue . . . . . . . . . . . . . . . . . . 18 88 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 18 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 1. Motivation 93 Many network resources are accessed primarily by name. DNS names 94 make up the bulk of those names. As a result, DNS names have become 95 fundamental elements in building security policies and user agent 96 behaviour. For example, domain names are used in attempts to 97 determine the scope for data sharing of HTTP state management cookies 98 [RFC6265] . The idea is to foil the attempts of attackers in (for 99 example) attackersite.co.tld from setting cookies for everyone in 100 co.tld. 102 Another example policy is a user interface convention that purports 103 to display the "real" domain name differently from other parts of the 104 fully-qualified domain name, in an effort to decrease the success of 105 phishing attacks. In this strategy, for instance, a domain name like 106 "www.bank.example.com.attackersite.tld" is formatted to highlight 107 that the name is inside "attackersite.tld", in the hope of thereby 108 reducing the user's impression of visiting "www.bank.example.com". 110 Issuers of X.509 certificates make judgements about administrative 111 boundaries around domains when issuing the certificates. For some 112 discussion of the relationship between DNS names and X.509 113 certificates, see [RFC6125]. 115 One way to build a reasonable policy is to treat each different 116 domain name distinctly. Under this approach, foo.example.org, 117 bar.example.org, and baz.example.org are all just different domains. 118 Such an approach can be awkward, however, when (as is often the case) 119 the real administrative boundary is a shared one (in this example, 120 example.org). Therefore, clients have attempted to make more 121 sophisticated policies. 123 Historically, policies were sometimes based on the DNS tree. Early 124 policies made a firm distinction between top-level domains and 125 everything else; but this was too naive, and later attempts were 126 based on inferences from the DNS names themselves. That did not work 127 well, because there is no way in the DNS to discover the boundaries 128 of administrative control around domain names. 130 Some have attempted to use the boundary of zone cuts (i.e. the 131 location of the zone's apex, which is at the SOA record; see 132 [RFC1034] and [RFC1035]). Unfortunately, that boundary is neither 133 necessary nor sufficient for these purposes: it is possible for a 134 large site to have many, administratively distinct subdomain-named 135 sites without inserting an SOA record, and it is also possible that 136 an administrative entity (like a company) might divide its domain up 137 into different zones for administrative reasons unrelated to the 138 purposes of sites named in that domain. It was also, prior to the 139 advent of DNSSEC, difficult to find zone cuts. Regardless, the 140 location of a zone cut is an administrative matter to do with the 141 operation of the DNS itself, and not useful for determining 142 relationships among services offered at names in the DNS. 144 What appears to be needed is a mechanism to determine administrative 145 boundaries in the DNS. That is, given services at two domain names, 146 one needs to be able to answer whether the first and the second are 147 under the same administrative control and same administrative 148 policies. We may call this state of affairs "lying within the same 149 policy realm". We may suppose that, if this information were to be 150 available, it would be possible to make useful decisions based on the 151 information. 153 A particularly important distinction for security purposes is the one 154 between names that are mostly used to contain other domains, as 155 compared to those that are mostly used to operate services. The 156 former are often "delegation-centric" domains, delegating parts of 157 their name space to others, and are frequently called "public suffix" 158 domains or "effective TLDs". The term "public suffix" comes from a 159 site, publicsuffix.org, that publishes a list of domains (henceforth, 160 the "public suffix list") that are used to contain other domains. 161 Not all, but most, delegation-centric domains are public suffix 162 domains; and not all public suffix domains need to do DNS delegation, 163 although most of them do. The reason for the public suffix list is 164 to make the distinction between names that must never be treated as 165 being in the same policy realm as another, and those that might be so 166 treated. For instance, if "com" is on the public suffix list, that 167 means that "example.com" lies in a policy realm distinct from that of 168 com. 170 Unfortunately, the public suffix list has several inherent 171 limitations. To begin with, it is a list that is separately 172 maintained from the list of DNS delegations. As a result, the data 173 in the public suffix list can diverge from the actual use of the DNS. 174 Second, because its semantics are not the same as those of the DNS, 175 it does not capture unusual features of the DNS that are a 176 consequence of its structure (see [RFC1034] for background on that 177 structure). Third, as the size of the root zone grows, keeping the 178 list both accurate and synchronized with the expanding services will 179 become difficult and unreliable. Perhaps most importantly, it puts 180 the power of assertion about the operational policies of a domain 181 outside the control of the operators of that domain, and in the 182 control of a third party possibly unrelated to those operators. 184 There have been suggestions for improvements of the public suffix 185 list, most notably in [I-D.pettersen-subtld-structure]. It is 186 unclear the extent to which those improvements would help, because 187 they represent improvements on the fundamental mechanism of keeping 188 metadata about the DNS tree apart from the DNS tree itself. 190 2. Background, terminology, and organization of this memo 192 The reader is assumed to be familiar with the DNS ([RFC1034] 193 [RFC1035]) and DNSSEC ([RFC4033] [RFC4034] [RFC4035] [RFC5155]). 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in RFC 2119 [RFC2119]. 199 Section 3 describes the mechanism in general terms, outlining two 200 different possible approaches and outlining the compromises in each 201 case. Definitions of the new RRTYPE is in Section 4, with two 202 different definitions to allow for the two different approaches. 203 There is some general discussion of the use of the RRTYPE is in 204 Section 5. Then, Section 6 offers an example portion of a DNS tree 205 that can be used to understand the ways in which the mechanism can be 206 used to draw inferences about administrative relationships. 207 Section 7 notes some limitations of the mechanism. Section 8 208 outlines how the mechanism might be used securely. 210 3. Overview of mechanism 212 This memo presents a way to assert a common administrative realm by 213 placing a resource record (RR) at DNS names within the policy realm. 214 The mechanism requires a new resource record type (RRTYPE) to enable 215 these assertions, called SOPA (for Start Of Policy Authority, echoing 216 the Start Of Authority or SOA record). While there are reported 217 difficulties in deploying new RRTYPEs, the only RRTYPE that could be 218 used to express all the necessary variables is the TXT record, and it 219 is unsuitable because it can also be used for other purposes. The 220 use of this mechanism does not require "underscore labels" to scope 221 the interpretation of the RR, in order to make it possible to use the 222 mechanism where the underscore label convention is already in use. 223 The SOPA RRTYPE is class-independent. 225 While many policies of the sort discussed in Section 1 appear to be 226 based on domain names, they are actually only partly based on them. 227 Usually, there are implicit rules that come from the destination port 228 [RFC6335] or scheme [RFC4395] (or both) in use. 230 It is possible to make those assumptions explicit, but at the cost of 231 expressing in the resulting record a tighter relationship between the 232 DNS and the services offered at DNS names. There are arguments to be 233 made for each approach. Section 3.1 and Section 3.2 explore the two 234 different approaches; this memo does not make a decision about which 235 strategy to adopt. If there are future developments of this memo, 236 one strategy will be selected. 238 It is worth observing that a policy realm relationship ought to be 239 symmetric: if example.com is in the same policy realm as example.net, 240 then example.net should be (it would seem) in the same policy realm 241 as example.com. In principle, then, if a SOPA RR at example.com 242 provides a target at example.net, there should be a complementary 243 SOPA RR at example.net with a target of example.com. Because of the 244 distributed nature of the DNS, and because the other administrative 245 divisions need not follow the policy realms, the only way to know 246 whether two names are in the same policy realm is to query at each 247 name, and to correlate the responses. 249 3.1. Identifying names as the scope for policy authority 251 The first approach provides, as the RDATA of a SOPA RR, a target name 252 that lies in the same policy realm as the owner name in the RR. For 253 convenience, in what follows this is sometimes called this the 254 "names-only" strategy. Such an approach is an assertion on the part 255 of the authoritative DNS server for the owner name in question that 256 there is a policy relationship between that owner name and the target 257 name. If a single name lies in the same policy realm as several 258 other target names, an additional RR is necessary for each such 259 relationship, with one exception. It is not uncommon for two 260 different names to have policy relationships among all the children 261 beneath them. Using the SOPA RR, it is possible to specify that the 262 target is all the names beneath a name, using a wildcard target. 264 This approach follows the traditional way that relationships are 265 expressed in the DNS, which is historically mostly between different 266 names. Aliases, for instance, redirect names or trees, and not names 267 or trees for specific RRTYPEs. It has the disadvantage, however, 268 that it may not provide enough information about the relationship 269 between two names to make all the inferences one might need about the 270 relationship. For instance, the relationship between two hosts might 271 depend on the protocol, port, and scheme in use: two domains might 272 share policy for the purposes of connections on port 80, but for no 273 other connections. [[anchor2: Could this be capured by using SRV or 274 NAPTR records on both sides of the policy relationship? Too slow? 275 --ajs@anvilwalrusden.com]] 277 3.2. Identifying names, schemes, and ports as the scope for policy 278 authority 280 The second approach provides, as the RDATA of a SOPA RR, a target 281 name that lies in the same policy realm as the owner name in the RR, 282 but can identify the relationship as pertaining only to certain ports 283 and schemes. In what follows, for convenience this is sometimes 284 called the "port-and-scheme" stragegy. It provides a way to cover 285 ranges of ports with a single resource record, and to cover all 286 schemes and ports with a single resource record. It does not, 287 however, permit arbitrary combinations of destination point and 288 schemes without using more than one RR. 290 This approach offers a mechanism to express relationships between 291 services at a domain name instead of merely between names. As a 292 disadvantage, however, it seems to step outside the usual scope of 293 the DNS, which concerns itself with names and not services offered at 294 those names. It might be argued that some RRTYPEs (notably SRV 295 [RFC2782] and NAPTR [RFC3403]) do relate to services; but in those 296 cases, it is an expression of services available at an already-named 297 host. It would be a significant innovation, perhaps in a bad 298 direction, to attempt to express these relationships in a single RR. 299 Since the names are under different administration, also, it is 300 entirely possible that the operators of the two domains do not agree 301 on the port ranges and schemas to be supported, creating an 302 intractable comparison problem for a client. 304 4. The SOPA Resource Record 306 Because of the two approaches outlined in Section 3.1 and 307 Section 3.2, this section provides two different outlines of the SOPA 308 resource record. This arrangement is pending the decision about 309 which strategy to adopt, at which time the discussion below will be 310 reduced to reflect that decision. 312 4.1. Thr SOPA Resource Record only for names 314 In this case, the SOPA resource record, type number [TBD1], includes 315 the following fields: 316 Name: The owner name of the RR. 317 TTL: The time to live for the RR. 318 Class: The CLASS for the RR. As of this writing, on the 319 contemporary Internet this is almost always "IN", but the SOPA RR 320 is class-independent. 321 SOPA: The RRTYPE field. 322 Target: A DNS name relative to the root that is in the same policy 323 realm as the SOPA RR's owner name. The name MUST be a DNS name 324 according to the rules in [RFC1034] and [RFC1035], except that the 325 left-most label of the target MAY be the wildcard character ("*"). 326 In addition, the target may be "."; in that case, the RR asserts 327 that there are no other names in the same policy realm. For 328 further discussion, see Section 5.1. The target MUST NOT be an 329 alias [RFC2181], such as the owner name of a CNAME [RFC1034], 330 DNAME [RFC6672], or other similar such resource records. 332 The SOPA RRTYPE's wire format is as follows: 334 [[anchor3: To follow if this idea (and this version of it) turns out 335 worth pursuing. It can be derived from above, however. 336 --ajs@anvilwalrusden.com]] 338 4.2. Thr SOPA Resource Record with ports and schemes 340 In this case, the SOPA resource record, type number [TBD1], includes 341 the following fields: 342 Name: The owner name of the RR. 343 TTL: The time to live for the RR. 344 Class: The CLASS for the RR. As of this writing, on the 345 contemporary Internet this is almost always "IN", but the SOPA RR 346 is class-independent. 347 SOPA: The RRTYPE field. 348 Starting port: The port number that begins the range to which this 349 SOPA RR applies. This is a 16 bit unsigned integer in network 350 byte order. The range is 0-65535. 351 Ending port: The port number that ends the range for which this SOPA 352 RR applies. This is a 16 bit unsigned integer in network byte 353 order. The range is 0-65535. 354 Scheme: The scheme to which the SOPA RR applies. The scheme SHOULD 355 be listed in the IANA Uniform Resource Identifier (URI) Schemes 356 registry [1]. [[anchor4: This is "SHOULD" right now, but I think 357 it should be "MUST". I can't think of a reason why not to make it 358 MUST. --ajs@anvilwalrusden.com]] Alternatively, the field may 359 contain the special value "*", in which case the SOPA RR applies 360 to all schemes, with a limitation: some clients use certain 361 schemes only for internal operations, and regardless of whether 362 those schemes are included in an SOPA RR, they MAY be ignored. 363 Target: A DNS name relative to the root that is in the same policy 364 realm as the SOPA RR's owner name. The name MUST be a DNS name 365 according to the rules in [RFC1034] and [RFC1035], except that the 366 left-most label of the target MAY be the wildcard character ("*"). 367 In addition, the target may be "."; in that case, the RR asserts 368 that there are no other names in the same policy realm. For 369 further discussion, see Section 5.1. The target MUST NOT be an 370 alias [RFC2181], such as the owner name of a CNAME [RFC1034], 371 DNAME [RFC6672], or other similar such resource records. 373 The SOPA RRTYPE's wire format is as follows: 375 [[anchor5: To follow if this idea (and this version of it) turns out 376 worth pursuing. It can be derived from above, however. 377 --ajs@anvilwalrusden.com]] 379 5. Use of the SOPA RRTYPE 381 SOPA RRs may have, in effect, three different functions. The 382 simplest is to make an assertion that two DNS names are in the same 383 policy realm. Under the port-and-scheme strategy, if the Starting 384 Port is 0, the Ending Port is 65535, the Scheme is "*", and the 385 Target is anything other than ".", then the SOPA record makes a claim 386 that the owner name and the target name are in the same policy realm 387 in every case. This is also the claim whenever the names-only 388 stragey is in use, and the RDATA has a target other than ".". 390 The second function, available only under the port-and-scheme 391 strategy, is to make an assertion that two DNS names are in the same 392 policy realm, but only for some subset of ports or schemes or both. 393 There is a 1:1 port mapping presumed in the way the SOPA RR is 394 structured, such that it is not possible to say that port N at the 395 owner name is related to port M at the target name. This is an 396 expedient for simplicity. For the same reasons of simplicity, the 397 SOPA RR permits linking all schemes between names, or else one 398 scheme; a given RR does not permit listing more than one scheme 399 without using the wildcard selector. 401 The third function is to make an assertion that no other name lies in 402 the same policy realm as the owner name. If there are names beneath 403 that owner name, this is a way for a DNS operator to assert that the 404 owner name is a public suffix. For more details, see Section 5.1. 406 There could be more than one SOPA resource record per owner name in a 407 response. Each domain name in the RDATA is treated as a part of the 408 same policy realm as the owner name in the original QNAME (subject to 409 the qualifications of scheme and port contained in the SOPA RR in the 410 port-and-scheme strategy). The QNAME from the query might not be the 411 owner name of the SOPA RR: if the original QNAME was an alias, then 412 the SOPA owner name will be different. 414 There are three possible responses to a query for the SOPA RRTYPE at 415 an owner name that are relevant to determining the policy realm. The 416 first is Name Error (RCODE=3, also known as NXDOMAIN). In this case, 417 the owner name itself does not exist, and no further processing is 418 needed. 420 The second is a No Data response [RFC2308] of any type. The No Data 421 response means that the owner name in the QNAME does not recognize 422 any other name as part of a common policy realm. 424 The final is a response with one or more SOPA resource records in the 425 Answer section. Each SOPA resource record asserts a relationship 426 between the owner name and the target name, according to the 427 functions of the SOPA RRTYPE outlined above. 429 Any other response is no different from any other sort of response 430 from the DNS, and is not in itself meaningful for determining the 431 policy realm of a name (though it might be meaningful for finding the 432 SOPA record). 434 5.1. Special target labels 436 5.1.1. The root target 438 An SOPA resource record with the single character "." (called the 439 "root target") in the RDATA is a positive assertion that no other 440 domain name falls inside the policy realm of the owner name. The 441 record has a special use: it may be used to bootstrap operation. A 442 client that has encountered the root target may remember the 443 existence of the root target even after the expiry of the TTL on the 444 RRset, until such time as a new query for the owner name may be made 445 successfully. This rule permits implementations to cache positive 446 statements of administrative isolation during disconnected periods, 447 thereby starting a subsequent session with the values of prior 448 affirmed policy. Apart from this bootstrapping use, and the ability 449 of such an RR to have a TTL independent of the negative TTL value for 450 the zone, this mechanism is semantically equivalent to a No Data 451 response. 453 It would be absurd for the root target for any given schema to exist 454 with any other SOPA resource record at that owner name. An 455 authoritative name server MAY refuse to serve a zone containing such 456 an inconsistency, MAY refuse to load a zone containing such an 457 inconsistency, or MAY suppress every SOPA RR at an owner name and 458 schema except that containing the root target. The name server side 459 of a recursive resolver MAY discard every SOPA RR at an owner name 460 except that containing the root target. Conforming servers MUST NOT 461 serve the root target and any other SOPA RR at the same owner name. 462 Clients receiving a SOPA RRset that includes the root target MUST 463 accept that RR, and discard any other RR in the RRset. 465 5.1.2. Wildcards in targets 467 The special character "*" in the Target field is used to match any 468 label, according to the wildcard label rules in section 4.3.3 of 469 [RFC1034]. Note that, because of the way wildcards work in the DNS, 470 is it not possible to place a restriction to the left of a wildcard; 471 so, for instance, example.*.example.com does not work. The effect is 472 maintained in this memo. An authoritative name server MUST NOT serve 473 an SOPA RR with erroneous wildcards, and clients receiving such an 474 SOPA RR MUST discard the RR. If the discarded RR is the last RR in 475 the answer section of the response, then the response is treated as a 476 No Data response. 478 5.2. What can be done with an SOPA RR 480 Use of an SOPA RR enables a site administrator to assert or deny 481 relationships between names. By the same token, it permits a a 482 consuming client to detect these assertions and denials. 484 Some of these relationships are currently impossible to indicate in 485 the DNS. For example, IDN character variants (see [RFC4290]) result 486 in situations where multiple labels are sometimes intended to be 487 treated as though they are the same. Without a mechanism for binding 488 the names together even loosely, such a goal cannot be achieved. 490 The use of SOPA RRs could either replace the public suffix list or 491 (more likely due to some limitations -- see Section 7) simplify and 492 automate the management of the public suffix list. A client could 493 use the responses to SOPA queries to refine its determinations about 494 http cookie Domain attributes. In the absence of SOPA RRs at both 495 owner names, a client might treat a Domain attribute as though it 496 were omitted. More generally, SOPA RRs would permit additional steps 497 similar to steps 4 and 5 in [RFC6265]. 499 SOPA RRs might be valuable for certificate authorities when issuing 500 certificates, because it would allow them to check whether two names 501 are related in the way the party requesting the certificate claims 502 they are. 504 6. An example case 506 For the purposes of discussion, it will be useful to imagine a 507 portion of the DNS, using the domain example.tld. A diagram of the 508 tree of this portion is in Figure 1. In the example, the domain 509 example.tld includes several other names: www.example.tld, 510 account.example.tld, cust1.example.tld, cust2.example.tld, 511 test.example.tld, cust1.test.example.tld, and cust2.test.example.tld. 513 tld 514 | 515 | 516 ------example ----- 517 / / | \ \ 518 / / | \ \ 519 / www account \ cust2 520 test \ 521 / \ cust1 522 cust1 cust2 524 Figure 1 526 In the example, the domain tld delegates the domain example.tld. 527 There are other possible cut points in the example, and depending on 528 whether the cuts exist there may be implications for the use of the 529 examples. See Section 6.1, below. 531 The (admittedly artificial) example permits us to distinguish a 532 number of different roles. To begin with, there are three parties 533 involved in the operation of services: 534 o OperatorV, the operator of example.tld; 535 o Operator1, the operator of cust1.example.tld; 536 o Operator2, the operator of cust2.example.tld. 538 Since there are three parties, there are likely three administrative 539 boundaries as well; but the example contains some others. For 540 instance, the names www.example.tld and example.tld are in this case 541 in the same policy realm. By way of contrast, account.example.tld 542 might be treated as completely separate, because OperatorV might wish 543 to ensure that the accounts system is never permitted to share 544 anything with any other name. By the same token, the names 545 underneath test.example.tld are actually the test-instance sites for 546 customers. So cust1.test.example.tld might be in the same policy 547 realm as cust1.example.tld, but test.example.tld is certainly not in 548 the same administrative realm as www.example.tld. 550 Finally, supposing that Operator1 and Operator2 merge their 551 operations, it seems that it would be useful for cust1.example.tld 552 and cust2.example.tld to lie in the same policy realm, without 553 including everything else in example.tld. 555 6.1. Examples of using the SOPA record for determining boundaries 557 This section provides some examples of different configurations of 558 the example tree in Section 6, above. The examples are not 559 exhaustive, but may provide an indication of what might be done with 560 the mechanism. [[anchor6: This needs to have examples of using the 561 ports and scheme added to it. Suggestions welcome. Also, I think 562 some examples could be made longer to make them clearer. Maybe 563 complete zone files in presentation form in an appendix? 564 --ajs@anvilwalrusden.com]] 566 6.1.1. One delegation, eight administrative realms, no root target 568 In this scenario, the example portion of the DNS name space contains 569 all and only the following SOPA records for the names-only strategy: 571 example.tld 86400 IN SOPA www.example.tld 572 www.example.tld 86400 IN SOPA example.tld 574 For the scheme-and-port strategy, these are the records instead: 576 example.tld 86400 IN SOPA 0 65535 * www.example.tld 577 www.example.tld 86400 IN SOPA 0 65535 * example.tld 579 Tld is the top-level domain, and has delegated example.tld. The 580 operator of example.tld makes no delegations. There are four 581 operators involved: the operator of tld; OperatorV; Operator1, the 582 operator of the services at cust1.example.tld and 583 cust1.test.example.tld; and Operator2, the operator of the services 584 at cust2.example.tld and cust2.test.example.tld. 586 In this arrangement, example.tld and www.example.tld positively claim 587 to be within the same policy realm. Every other name stands alone. 588 A query for an SOPA record at any of those other names will result in 589 a No Data response, which means that none of them include any other 590 name in the same policy realm. As a result, there are eight separate 591 policy realms in this case: tld, {example.tld and www.example.tld}, 592 test.example.tld, cust1.test.example.tld, cust2.test.example.tld, 593 account.example.tld, cust1.example.tld, and cust2.example.tld. 595 6.1.2. One delegation, eight administrative realms, root targets 597 This example mostly works the same way as the one in Section 598 Section 6.1.1, but there is a slight difference. In this case, in 599 addition to the records listed in Section 6.1.1, both tld and 600 test.example.tld publish root targets in their SOPA records. For 601 names-only: 603 tld 86400 IN SOPA . 604 test.example.tld 86400 IN SOPA . 606 For scheme-and-port: 608 tld 86400 IN SOPA 0 65535 * . 609 test.example.tld 86400 IN SOPA 0 65535 * . 611 The practical effect of this is largely the same as the previous 612 example, except that these expressions of policy last 86,400 seconds 613 instead of the length of time on the negative TTL in the relevant SOA 614 for the zone. Many zones have short negative TTLs because of 615 expectations that newly-added records will show up quickly. This 616 mechanism permits such names to express their administrative 617 isolation for predictable periods of time. Moreover, because clients 618 are permitted to retain these records during periods when DNS service 619 is not available, a client could go offline for several weeks, and 620 return to service with the presumption that test.example.tld is still 621 not in any policy realm with any other name. 623 6.1.3. Two delegations, seven or eight policy realms, root targets 625 In this scenario, example.tld delegates the name test.example.tld. 626 In this case, in addition to the SOPA record at test.example.tld, 627 there is an SOA record for test.example.tld. So, there are the same 628 SOPA records as in Section 6.1.2. The addition of the SOA record for 629 test.example.tld does not affect the relationship between 630 test.example.tld and example.tld. At this point, there are eight 631 policy realms. 633 Next, the Operator1 determines that it is safe to treat the test 634 instance and production instance as being in the same policy realm. 635 To begin with, Operator1 asks OperatorV to add the following record 636 to the test.example.tld zone for the names-only case: 638 cust1.test.example.tld 86400 IN SOPA cust1.example.tld 640 And for the scheme-and-port case: 642 cust1.test.example.tld 86400 IN SOPA 0 65535 * cust1.example.tld 644 This arrangement is not complete yet. Until a record is also added 645 at cust1.example.tld, Operator1's intention is only half fulfilled. 646 The service at cust1.test.example.tld treats cust1.example.tld as 647 part of a common policy realm, but the converse is not the case. 648 [[anchor7: I can't decide whether there's anything useful in this 649 configuration. Thoughts? I also can't decide whether this is still 650 8 admin realms, 7 admin realms but broken, or 7 admin realms from one 651 perspective and 8 from another. --ajs@anvilwalrusden.com]] 653 To complete the process, Operator1 asks OperatorV to add the 654 following record to the example.tld zone in the names-only case: 656 cust1.example.tld 86400 IN SOPA cust1.test.example.tld 658 In the scheme-and-port case: 660 cust1.example.tld 86400 IN SOPA 0 65535 * cust1.test.example.tld 662 Once this is complete, both names treat the other as part of the same 663 policy realm. In the end, the example segment of the DNS expresses 664 the following seven policy realms: tld, {example.tld, 665 www.example.tld}, test.example.tld, {cust1.test.example.tld, 666 cust1.example.tld}, cust2.example.tld, account.example.tld, 667 cust2.test.example.tld. 669 7. Limitations of the approach and other considerations 671 There are four significant problems with this proposal, all of which 672 are related to using DNS to deliver the data. 674 The first is that new DNS RRTYPEs are difficult to deploy. While 675 adding a new RRTYPE is straightforward, many provisioning systems do 676 not have the necessary support and some firewalls and other edge 677 systems continue to filter RRTYPEs they do not know. 679 The second is that it is difficult for an application to obtain data 680 from the DNS. The TTL on an RRset, in particular, is usually not 681 available to an application, even if the application uses the 682 facilities of the operating system to deliver other parts of an 683 unknown RRTYPE. 685 The third, which is mostly a consequence of the above two, is that 686 there is a significant barrier to adoption: until browsers have 687 mostly all implemented this, operations need to proceed as though 688 nobody has. But browsers will need to support two mechanisms for 689 some period of time if they are to implement this mechanism at all, 690 and they are unlikely to want to do that. This may mean that there 691 is no reason to implement, which also means no reason to deploy. 692 This is made worse because, to be safe, the mechanism really needs 693 DNSSEC, and performing DNSSEC validation at end points is still an 694 unusual thing to do. This limitation may not be as severe for use- 695 cases that are directed higher in the network (such as using this 696 mechanism as an automatic feed to keep the public suffix list 697 updated, or for the use of CAs when issuing certificates. 699 Finally, in many environments the system hosting the application has 700 only proxied access to the Internet, and cannot query the DNS 701 directly. It is not clear how such clients could ever possibly 702 retrieve the SOPA record for a name. 704 7.1. Handling truncation 706 It is possible to put enough SOPA records into a zone such that the 707 resulting response will exceed DNS or UDP protocol limits. This is 708 especially true in the case where one wishes to take advantage of the 709 scheme-and-port approach, and one expresses many different such 710 relationship. In such cases, a UDP DNS response will arrive with the 711 TC (truncation) bit set. An SOPA response with the TC bit must be 712 queried again in order to retrieve a complete response, in order to 713 ensure that there is no missing root target (see Section 5.1.1), 714 generally using TCP. This increases the cost of the query, increases 715 the time to being able to use the answer, and may not work at all in 716 networks where administrators mistakenly block port 53 using TCP. 718 8. Security Considerations 720 This mechanism enables publication of assertions about administrative 721 relationships of different DNS-named systems on the Internet. If 722 such assertions are accepted without checking that both sides agree 723 to the assertion, it would be possible for one site to become an 724 illegitimate source for data to be consumed in some other site. In 725 general, assertions about another name should never be accepted 726 without querying the other name for agreement. 728 Undertaking any of the inferences suggested in this draft without the 729 use of the DNS Security Extensions exposes the user to the 730 possibility of forged DNS responses. 732 9. IANA Considerations 734 IANA will be requested to register the SOPA RRTYPE if this proceeds. 736 10. Acknowledgements 738 The author thanks Adam Barth, Dave Crocker, Jeff Hodges, John 739 Klensin, Murray Kucherawy, Gervase Markham, Patrick McManus, Henrik 740 Nordstrom, Yngve N. Pettersen, Eric Rescorla, Thomas Roessler, Peter 741 Saint-Andre, and Maciej Stachowiak for helpful comments. 743 11. References 744 11.1. Normative References 746 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 747 STD 13, RFC 1034, November 1987. 749 [RFC1035] Mockapetris, P., "Domain names - implementation and 750 specification", STD 13, RFC 1035, November 1987. 752 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 753 Requirement Levels", BCP 14, RFC 2119, March 1997. 755 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 756 Rose, "DNS Security Introduction and Requirements", 757 RFC 4033, March 2005. 759 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 760 Rose, "Resource Records for the DNS Security Extensions", 761 RFC 4034, March 2005. 763 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 764 Rose, "Protocol Modifications for the DNS Security 765 Extensions", RFC 4035, March 2005. 767 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 768 Security (DNSSEC) Hashed Authenticated Denial of 769 Existence", RFC 5155, March 2008. 771 11.2. Informative References 773 [I-D.pettersen-subtld-structure] 774 Pettersen, Y., "The Public Suffix Structure file format 775 and its use for Cookie domain validation", 776 draft-pettersen-subtld-structure-09 (work in progress), 777 March 2012. 779 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 780 Specification", RFC 2181, July 1997. 782 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 783 NCACHE)", RFC 2308, March 1998. 785 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 786 specifying the location of services (DNS SRV)", RFC 2782, 787 February 2000. 789 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 790 Part Three: The Domain Name System (DNS) Database", 791 RFC 3403, October 2002. 793 [RFC4290] Klensin, J., "Suggested Practices for Registration of 794 Internationalized Domain Names (IDN)", RFC 4290, 795 December 2005. 797 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 798 Registration Procedures for New URI Schemes", BCP 35, 799 RFC 4395, February 2006. 801 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 802 Verification of Domain-Based Application Service Identity 803 within Internet Public Key Infrastructure Using X.509 804 (PKIX) Certificates in the Context of Transport Layer 805 Security (TLS)", RFC 6125, March 2011. 807 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 808 April 2011. 810 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 811 Cheshire, "Internet Assigned Numbers Authority (IANA) 812 Procedures for the Management of the Service Name and 813 Transport Protocol Port Number Registry", BCP 165, 814 RFC 6335, August 2011. 816 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 817 DNS", RFC 6672, June 2012. 819 URIs 821 [1] 823 Appendix A. Discussion Venue 825 This Internet-Draft is discussed on the applications area working 826 group mailing list: apps-discuss@ietf.org. 828 Appendix B. Change History 830 00 to 01: 831 * Changed the mnemonic from BOUND to AREALM 832 * Added ports and scheme to the RRTYPE 833 * Added some motivating text and suggestions about what can be 834 done with the new RRTYPE 835 * Removed use of "origin" term, because it was confusing. The 836 document filename preserves "origin" in the name in order that 837 the tracker doesn't lose the change history, but that's just a 838 vestige. 840 * Removed references to cross-document information sharing and 841 ECMAScript. I don't understand the issues there, but Maciej 842 Stachowiak convinced me that they're different enough that this 843 mechanism probably won't work. 844 * Attempted to respond to all comments received. Thanks to the 845 commenters; omissions and errors are mine. 846 01 to 02: 847 * Changed mnemonic again, from AREALM to SOPA. This in response 848 to observation by John Klensin that anything using 849 "administrative" risks confusion with the standard 850 administrative boundary language of zone cuts. 851 * Add discussion of two strategies: name-only or scheme-and-port. 852 * Increase prominence of utility to CAs. This use emerged in 853 last IETF meeting. 855 Author's Address 857 Andrew Sullivan 858 Dyn, Inc. 859 150 Dow St 860 Manchester, NH 03101 861 U.S.A. 863 Email: asullivan@dyn.com