idnits 2.17.1 draft-deccio-dbound-organizational-domain-policy-03.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 30 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 -- The document date (July 1, 2016) is 2855 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4592' is defined on line 822, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) == Outdated reference: A later version (-04) exists of draft-levine-orgboundary-02 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Deccio 3 Internet-Draft Verisign Labs 4 Intended status: Informational July 1, 2016 5 Expires: January 2, 2017 7 Organizational Domains and Use Policies for Domain Names 8 draft-deccio-dbound-organizational-domain-policy-03 10 Abstract 12 Various Internet protocols and applications require some mechanism 13 for identifying policy surrounding the use Domain Name System (DNS) 14 names. In this document we describe an extensible system in which 15 domain name policies can be discovered at various levels in the DNS 16 tree. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 2, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . 3 54 2. Solution Concepts . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Designating Organizational Domain and Use Policy . . . . . . 4 56 3.1. ODUP Name . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. ODUP Statement . . . . . . . . . . . . . . . . . . . . . 5 58 3.2.1. Version . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2.2. Directives . . . . . . . . . . . . . . . . . . . . . 5 60 3.3. Directive Considerations . . . . . . . . . . . . . . . . 6 61 3.3.1. all Directive . . . . . . . . . . . . . . . . . . . . 6 62 3.3.2. Directive Defaults . . . . . . . . . . . . . . . . . 7 63 3.3.3. org Directive . . . . . . . . . . . . . . . . . . . . 7 64 3.3.4. bound Directive . . . . . . . . . . . . . . . . . . . 7 65 3.3.4.1. Argument to bound directive . . . . . . . . . . . 8 66 3.3.5. fetch Directive . . . . . . . . . . . . . . . . . . . 9 67 4. Identifying Organizational Domain and Use Policy . . . . . . 9 68 5. Policy-negative Realm . . . . . . . . . . . . . . . . . . . . 11 69 5.1. PSL/ODUP Equivalence Example . . . . . . . . . . . . . . 12 70 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 6.1. ODUP Resolution . . . . . . . . . . . . . . . . . . . . . 13 72 7. Example Application Use . . . . . . . . . . . . . . . . . . . 16 73 7.1. Public Suffix List Replacement . . . . . . . . . . . . . 16 74 7.2. HTTP Cookies . . . . . . . . . . . . . . . . . . . . . . 17 75 7.3. DMARC . . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 81 11.2. Informative References . . . . . . . . . . . . . . . . . 19 82 Appendix A. Pseudo-code for ODUP Resolution . . . . . . . . . . 20 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 85 1. Introduction 87 The concepts of domains, subdomains, and administrative delegation 88 are fundamental to the Domain Name System (DNS) [RFC1034] [RFC1035]. 89 The DNS namespace is hierarchical, and the management of subdomain 90 space is delegated by one entity to another throughout. However, 91 policies governing the use of domain names do not always align with 92 those lines of delegation. There are currently no generally reliable 93 methods to reconcile domain names with policy for their use. 95 As a prominent example, HTTP cookies [RFC6265] have traditionally 96 used ancestral relationships to determine allowable scope of 97 information sharing and authorization. For example, the server at 98 www.example.com might set a cookie with a Domain attribute of 99 example.com, because it is a subdomain of that name. However, this 100 simplistic authorization does not account for some cases, such as 101 cookies with a Domain attribute corresponding to a so-called "public 102 suffix". [RFC6265] indicates that many user agents reject such 103 cookies due to security and privacy concerns. Even so, the public 104 suffix designation is not apparent from either the names themselves 105 or the delegations leading down to them from the root. Instead, a 106 resource, such as Mozilla's Public Suffix List (PSL) [PSL], is used 107 to identify public suffixes. 109 Another challenge with domain names is the ability to identify their 110 respective Organizational Domains, for applications like Domain-based 111 Message Authentication, Reporting, and Conformance (DMARC) [RFC7489]. 112 [RFC7489] includes heuristics to identify an organizational domain 113 using a public suffix list (e.g., Mozilla's PSL [PSL]) "in the 114 absence of more accurate methods". Other applications have similarly 115 relied on a public suffix list to define an organizational domain, 116 whether for policy, forensics, or simple identification. However, 117 defining a "more accurate" method is desirable. 119 In this document we describe a framework for more accurately 120 identifying policy and organizational domains on a per-domain name 121 basis. The system described adds customization and flexibility to 122 existing systems while being fully backwards compatible with previous 123 mechanisms and default behaviors. 125 1.1. Reserved Words 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 2. Solution Concepts 133 The major questions to be addressed by a solution in this space are 134 the identification of policy for a given domain name and the 135 identification of an organizational domain for a given domain name. 136 The questions are related in that the policy for a domain name might 137 depend on its organizational domain name, either because that policy 138 is defined by its organizational domain or because it depends on 139 organizational boundaries. 141 In previous solutions, policy has almost always been bound by direct 142 ancestral relationships. While that constraint might be lifted by 143 future solutions, the solution documented herein respects the 144 hierarchical order in the DNS: policies between domain names in which 145 one is not a sub-domain of the other are non-existent and out of 146 scope for this document. 148 In this context the organizational domain for a given domain name 149 will always be an ancestor of the domain name, if not the domain name 150 itself. Prior to this draft, one of the heuristics for determining 151 the organizational domain was using a public suffix list: the 152 organizational domain is the series of labels comprising the public 153 suffix portion of the name, plus one label ([RFC6265]). With that 154 methodology, for any given domain name, not a public suffix, there 155 was exactly one possible organizational domain. In this work, an 156 organizational domain can be designated at (mostly) arbitrary levels 157 in the domain name's ancestry. 159 The notion of a "public suffix" (i.e., as included in a public suffix 160 list, such as Mozilla's PSL [PSL]) has brought to light the nature of 161 policy associated with "registry controlled domains" ([RFC6265]), 162 sometimes viewed as extensions of top-level domains (TLDs), which 163 have similar policy. While domain names might appear in current 164 versions of such lists for a variety of reasons, the impact of their 165 designation is consistent: they are treated as special-purpose names, 166 limited in their use by applications. For example, HTTP cookies with 167 a Domain attribute corresponding to a public suffix are rejected by 168 most user agents. Similarly, public suffixes cannot be 169 organizational domains, e.g., for DMARC use. We refer to the set of 170 names above the boundary separating public suffixes from their 171 descendants as "policy-negative". 173 3. Designating Organizational Domain and Use Policy 175 In this section we describe the technical implementation for 176 designating organization domain and use policy (ODUP) for domain 177 names. 179 3.1. ODUP Name 181 The "_odup" label, when used as part of a domain name, carries 182 special meaning in the context of defining organizational domains and 183 policy, and the resulting domain name is referred to as an ODUP name. 184 In an ODUP name the sequence of labels after the _odup label (i.e., 185 higher in the DNS namespace tree) comprise the organizational domain, 186 and the concatenation of the sequence of labels before it (i.e., 187 lower in the DNS namespace tree) with those after it comprise the 188 policy domain. 190 For example, given the ODUP name foo.bar._odup.example.com, the 191 organizational domain is example.com, and the policy domain is 192 foo.bar.example.com. 194 3.2. ODUP Statement 196 A TXT record at an ODUP name contains an ODUP statement for the 197 policy domain. The formal syntax for an ODUP statement, using 198 [RFC5234], is the following: 200 statement = version *( SP qual-directive ) 202 version = "v=odup1" 204 qual-directive = qualifier directive [ arg-sep arg ] 206 qualifier = %x2B / %x2D 207 ; addition sign (+) or hyphen (-) 209 directive = 1*( directive-char ) 210 ; one or more s 212 directive-char = ALPHA / DIGIT / %x2D 213 ; letter, digit, or hyphen 215 arg-sep = %x3A 216 ; colon (:) 218 arg = 1*( VCHAR ) 219 ; one or more s 221 3.2.1. Version 223 The ODUP statement begins with a version declaration. At this time, 224 the only defined version is "odup1", so the record MUST begin with 225 "v=odup1". 227 3.2.2. Directives 229 Following the version declaration and a space is a series of zero or 230 more space-separated directives, each prepended with a qualifier: 231 either "+" or "-". Additionally, each directive may optionally 232 include a single argument, which is affixed to the end of the 233 directive, immediately after a colon (":"). 235 Only two policy-related directives are defined in this document. 236 Unless otherwise specified, no arguments are defined for the 237 directives. 239 o httpcookie - whether the domain name may (+) or may not (-) be 240 used as the value of the Domain attribute of an HTTP Cookie. 242 o all - for directives not otherwise specified, the default policy 243 is allow (+) or deny (-). 245 The following directives do not carry policy information, but 246 designate organizational domains or boundaries, or offer other non- 247 policy information. Only the "+" qualifier is valid with these 248 directives: 250 o org - specifies that the policy domain itself is an organizational 251 domain (See Section 3.3.3). 253 o bound - designates an organizational boundary below the policy 254 domain. Domain names below that boundary are organizational 255 domains (See Section 3.3.4). The bound directive may optionally 256 include a numeric argument specifying the number of labels below 257 the "_odup" label within the domain name owning the ODUP 258 statement. This is used to detect wildcard synthesis by ODUP 259 resolvers (see Section 3.3.4.1). 261 o fetch - designates a means for retrieving an ODUP policy realm in 262 its entirety for local use. An argument is required, which 263 designates one or more comma-separated URLs to use for retrieving 264 the realm (See Section 3.3.5). 266 3.3. Directive Considerations 268 3.3.1. all Directive 270 An ODUP statement MUST NOT have more than one "all" directive (with 271 its accompanying qualifier). If no "all" directive is supplied, an 272 implicit "+all" is applied. 274 The "all" directive SHOULD appear last in an ODUP statement. This is 275 for readability purposes only, as directive order otherwise doesn't 276 matter. 278 Because the "all" directive specifies the default policy for a given 279 policy domain, other directives in the same statement simply specify 280 exceptions to that default policy. Thus, the qualifier for 281 directives other than "all" SHOULD be the opposite as that used with 282 "all". The only side effect to non-adherence to this recommendation 283 is the existence of superfluous directives (i.e., because they are 284 already implied with the default policy). Implementors MAY add such 285 directives nonetheless, for added readability. 287 3.3.2. Directive Defaults 289 The presence of each directive with its qualifier indicates intended 290 policy associated with the name in question. Because the this draft 291 introduces new behaviors, the positive ("+") value for any directive 292 MUST match default behavior preceding this document, in order to 293 maintain backwards compatibility. In this manner, the default policy 294 ("+all") matches previous behavior. 296 3.3.3. org Directive 298 The "org" directive designates a specific domain name as an 299 organizational domain. Because the "org" directive designates a 300 domain name as an organizational domain, subdomains of ODUP names 301 whose statements include the "org" directive SHOULD NOT exist, and 302 subdomains MUST NOT be queried for policy. 304 For example, given the following ODUP statement: 306 example._odup.com. IN TXT "v=odup1 +org" 308 example.com is an organizational domain, and further policy 309 information would be sought in the "_odup.example.com" DNS domain. 310 The domain name foo.example._odup.com is irrelevant. 312 An "org" directive MUST NOT appear together with a "bound" directive 313 in the same ODUP statement. Additionally, the "org" directive SHOULD 314 NOT be accompanied by any other directives; any other directives MUST 315 be ignored by software interpreting the statement. 317 3.3.4. bound Directive 319 Rather than specifying an organizational domain directly, like the 320 "org" directive does, the "bound" directive specifies organizational 321 domains indirectly by designating a boundary below which the 322 organization domain exists. The actual boundary might not be 323 immediately below the policy name specified by the "bound" statement 324 at the corresponding ODUP name. Rather, it is a potentially uneven 325 line dividing the subdomain space below that name. This boundary is 326 drawn immediately below the lowest name in an unbroken line of 327 descendants of the ODUP name for which there are no ODUP statements 328 that include "org". Note that this line of descendants includes ODUP 329 names with statements including "bound", statements with policy 330 directives other than "org" and "bound", and existing ODUP names with 331 no statements at all. It does not, however, include non-existent 332 ODUP names. 334 For example, suppose the ODUP information for www.sub.example.com is 335 being sought, and within the com organizational domain we find the 336 following ODUP statement: 338 example._odup.com. IN TXT "v=odup1 +bound" 340 Having this knowledge, if a subsequent query for 341 sub.example._odup.com/TXT results in a name error (NXDOMAIN), then 342 the boundary exists immediately below example.com, such that 343 sub.example.com is the organizational domain. Likewise, if the query 344 for sub.example._odup.com/TXT results in an ODUP statement with the 345 "org" directive, such also indicates that the boundary is immediately 346 below example.com. However, if the query results in a NODATA 347 response, then the boundary is below sub.example.com, and additional 348 queries are required to determine its precise location. 350 Subdomains of ODUP names with statements that include a "bound" 351 directive are not restricted in the same way as they are in 352 connection with the use of the "org" directive (See Section 3.3.3). 353 However, subdomains of ODUP names having "bound" statements SHOULD 354 NOT include statements that don't include "org" or "bound". Any such 355 statements MUST be ignored. 357 "bound" directives SHOULD only be used in the policy-negative realm 358 (see Section 5). In other places, the same effect can typically be 359 accomplished through use of the "org" directive. 361 Finally, a "bound" directive MUST NOT appear together with an "org" 362 directive in the same ODUP statement. 364 3.3.4.1. Argument to bound directive 366 Wildcard ODUP names (i.e., those whose leftmost, or lowest, label is 367 *[RFC4592]) are just as valid for ODUP names as they are generally 368 for the DNS. However, for wildcard ODUP names whose corresponding 369 statements include "bound", the boundary might not be detected 370 properly if it is not known that the record is synthesized from a 371 wildcard. Specifically, the wildcard synthesis would always yield a 372 positive answer, and the lack of an NXDOMAIN response would cause an 373 application identifying boundaries to continue to look for the 374 longest match. 376 The numeric argument to the bound directive is used when an ODUP 377 statement is used at a wildcard DNS name. The value is the number of 378 non-* labels below the "_odup" label. For example, the argument to 379 the "bound" directive for the ODUP name *.b.a._odup.example.com. 380 would always be 2. 382 3.3.5. fetch Directive 384 The "fetch" directive is used to designate one or more Uniform 385 Resource Identifiers (URIs) [RFC3986] from which the ODUP statements 386 for a given organizational domain can be downloaded for local 387 reference. The URIs, delimited by semi-colons, comprise the argument 388 to the "fetch" directive. 390 The statements for an organizational domain are downloaded either via 391 zone transfer [RFC1034], HTTP [RFC7230] [RFC7231], or [RFC2818] 392 HTTPS. In the case of an HTTP(s) download, the file is maintained in 393 text format, structured as DNS zone master file [RFC1034] and 394 retrieved using the GET method [RFC7231]. In any case, the contents 395 of the download correspond to the records comprising the "_odup" 396 subdomain of the organizational domain. 398 The URI for a zone transfer uses "axfr" as its scheme. The host 399 component is optional; if not specified, any of the authoritative 400 servers advertised in the NS record set may be used. The path 401 component is blank. The following are valid URIs for use in the 402 fetch directive for example.com: 404 axfr:// 406 axfr://ns1.example.com 408 http://www.example.com/odup.zone 410 4. Identifying Organizational Domain and Use Policy 412 The process of identifying organizational domains and policies is 413 referred to as ODUP resolution. It involves methodically issuing DNS 414 queries for DNS records of type TXT at ODUP names. The desired 415 outcome for ODUP resolution is an organizational domain, a policy 416 domain, and a policy. The process is iterative and completes in O(n) 417 (upper bound) time, where n corresponds to the number of labels in 418 the name. The algorithm finds the ODUP statement corresponding to 419 the policy name that mostly closely matches the domain name being 420 looked up within the lowest designated organizational domain. Each 421 iteration is as follows, beginning with the single right-most label 422 (i.e., TLD) as the organizational domain. We use www.example.com to 423 illustrate policy lookup in each step. 425 1. Reset the longest matching record and the longest existing name. 427 2. Begin with the ODUP name formed by prepending the "_odup" label 428 to the current organizational domain, and with each subsequent 429 iteration increase the number of policy domain labels below the 430 "_odup" label by one to form an ODUP name. 432 Example: If the current organizational domain is com, then the 433 iterative ODUP names would be: _odup.com, example._odup.com, 434 www.example._odup.com. 436 3. Issue a query using the ODUP name formed in the previous step 437 for a record of type TXT. 439 4. If the query results in response code 0 (NOERROR), then save 440 this ODUP name as the longest existing name. 442 5. If the query yields a response with an ODUP policy, and either 443 the ODUP statement includes an "org" or "bound" directive or the 444 previous longest matching record includes neither an "org" nor a 445 "bound" directive, then save the record as the longest matching 446 record. 448 6. If the query yields a response with an ODUP policy that includes 449 an "org" directive, then go to Step 11. 451 7. If the query yields a response with an ODUP policy that includes 452 a "bound" directive, and the response is derived from a 453 wildcard, go to Step 11. 455 8. If the query results in response code 3 (name error or 456 NXDOMAIN), go to Step 11. 458 Example: If a query for _odup.com results in a name error, then 459 we don't continue to example._odup.com. 461 9. If all the labels have been exhausted, then go to Step 11. 463 Example: If the current organizational domain is com, and we 464 have already looked for policy at the ODUP names _odup.com, 465 example._odup.com, and www.example._odup.com, then we go to Step 466 11. 468 10. Return to step Step 2, increasing the number of labels of policy 469 domain. 471 Example: If the current organizational domain is com, and we 472 have just looked for policy at _odup.com, then we would now look 473 for policy at example._odup.com. 475 11. If there was no positive response (i.e., longest matching record 476 is not set), then return an empty policy under the current 477 organizational domain. 479 12. If the longest matching record includes an "org" directive, then 480 return to Step 1, using the longest matching policy domain as 481 the organizational domain. 483 Example: If the ODUP statement at example._odup.com included an 484 "org" directive, then we would next look for policy at 485 _odup.example.com, then www._odup.example.com. 487 13. If the longest matching record includes a "bound" directive, and 488 the number of labels in the longest existing name is less than 489 those in the name whose policy is being looked up, then return 490 to Step 1, using the longest existing name domain, plus one 491 label, as the organizational domain. 493 Example: If the ODUP statement at _odup.com included a "bound" 494 directive, then we would next look for policy at 495 _odup.example.com, then www._odup.example.com. 497 14. Return the record corresponding to the longest matching policy 498 domain. 500 Appendix A contains the pseudo-code for this algorithm. 502 5. Policy-negative Realm 504 The policy-negative realm is the portion of the DNS namespace that 505 corresponds to so-called public suffixes. The ODUP policies defining 506 the policy-negative realm fall under the _odup subdomain of each TLD 507 and consist of ODUP statements that use the "bound", "org", and 508 "-all" directives. 510 The result is that the ODUP statements defining the policy-negative 511 realm comprise a PSL-like list. In fact, the statements comprising 512 the policy-negative realm can be derived from Mozilla's [PSL] and 513 vice-versa. See, for example, the tables in Section 5.1. This is 514 useful for several reasons. The current applications and libraries 515 using the PSL have a way to work in parallel, one being derived from 516 the other, for backwards compatibility and possible transition. It 517 also enables consumer applications to work (fully or partially) 518 offline by simply downloading all the policy-negative statements when 519 those are sufficient for the purposes of the application. 521 To enable local reference of ODUP statements within the policy- 522 negative realm, "fetch" statements SHOULD be specified for ODUP 523 statements found at ODUP names immediately under TLDs, e.g., 524 _odup.com. Because the nature of TLDs has changed [NewgTLDs], some 525 TLDs might not have a complete negative policy, and thus might be 526 "below" the policy negative realm. Such TLDs MAY choose to use a 527 default policy (which is not negative) by not publishing an ODUP 528 statement at all, in which case the inclusion of the "fetch" 529 directive does not apply. 531 Even when a self-contained listing of the policy-negative names is 532 locally available but insufficient for the needs of the consumer 533 application (i.e., a more specific assurance of policy is necessary), 534 this resource can provide an efficient starting place for ODUP 535 resolution. Rather than starting with the TLD as the organizational 536 domain, the shortest organizational domain below the policy-negative 537 boundary is used first. This increases efficiency by avoiding 538 network latency associated with unnecessary DNS lookups. 540 Working from a locally available version of the policy-negative realm 541 is not only more efficient, but it also minimizes information 542 disclosure to delegating authorities and is thus more privacy- 543 adhering. 545 Directives other than "bound", "org", "fetch", and "-all" MUST NOT be 546 used in the policy-negative realm. 548 5.1. PSL/ODUP Equivalence Example 550 +---+-----------+ 551 | | PSL Entry | 552 +---+-----------+ 553 | 1 | uk | 554 | 2 | co.uk | 555 | 3 | *.ck | 556 | 4 | !www.ck | 557 +---+-----------+ 559 Select PSL Entries 561 Note that "fetch" directives are excluded to maximize space. 563 +---+---------------+-------------------------+ 564 | | ODUP Name | ODUP Statement | 565 +---+---------------+-------------------------+ 566 | 1 | _odup.uk. | "v=odup1 +bound -all" | 567 | 2 | co._odup.uk. | "v=odup1 +bound -all" | 568 | 3 | *._odup.ck. | "v=odup1 +bound:0 -all" | 569 | 4 | www._odup.ck. | "v=odup1 +org" | 570 +---+---------------+-------------------------+ 572 Corresponding ODUP Names and Statements 574 6. Examples 576 We provide several examples and in this section of ODUP designation, 577 resolution, and potential application. 579 6.1. ODUP Resolution 581 Example DNS entries are listed in Table 1 and illustrated in 582 Figure 1. The resulting policies are listed in Table 3. 584 +-------------+-----------------+-------------------------+ 585 | Org. Domain | ODUP Name | ODUP Statement | 586 +-------------+-----------------+-------------------------+ 587 | uk. | _odup.uk. | "v=odup1 +bound -all" | 588 | uk. | co._odup.uk. | "v=odup1 +bound -all" | 589 | ck. | _odup.ck. | "v=odup1 +bound -all" | 590 | ck. | *._odup.ck. | "v=odup1 +bound:0 -all" | 591 | ck. | www._odup.ck. | "v=odup1 +org" | 592 | a.uk. | c.b._odup.a.uk. | "v=odup1 +org" | 593 | a.uk. | e._odup.a.uk. | "v=odup1 -httpcookie" | 594 | c.b.a.uk. | _odup.c.b.a.uk. | "v=odup1 -httpcookie" | 595 +-------------+-----------------+-------------------------+ 597 Example ODUP statements and corresponding ODUP names and 598 organizational domains. Note that "fetch" directives are excluded to 599 maximize space. 601 Table 1: Example DNS entries 602 . 603 | 604 +-------+-------+ 605 / \ 606 uk * ck * 607 | | 608 +---+---+ +-+-+ 609 / \ / \ 610 ===+=== \ / ===+=== 611 a co h www 612 | | | 613 +-+-+ | | 614 / \ ===+=== ===+=== 615 b e * g i 616 | | 617 ===+=== | 618 c * f 619 | 620 d 622 Illustration of the namespace associated with ODUP names and 623 statements listed in Table 1. Each node represents a DNS label in 624 its place in the DNS namespace hierarchy. Double horizontal lines 625 (====) represent organizational boundaries, and asterisks (*) 626 represent explicit policy statements. 628 Figure 1 630 +-------------+----------------------+---------------+------+ 631 | Domain Name | DNS Queries | Responses | Step | 632 +-------------+----------------------+---------------+------+ 633 | uk | _odup.uk/TXT | +bound -all | 14 | 634 | a.uk | _odup.uk/TXT | +bound -all | 10 | 635 | | a._odup.uk/TXT | NXDOMAIN | 13 | 636 | | _odup.a.uk/TXT | NODATA | 11 | 637 | b.a.uk | _odup.uk/TXT | +bound -all | 10 | 638 | | a._odup.uk/TXT | NXDOMAIN | 13 | 639 | | _odup.a.uk/TXT | NODATA | 10 | 640 | | b._odup.a.uk/TXT | NODATA | 11 | 641 | c.b.a.uk | _odup.uk/TXT | +bound -all | 10 | 642 | | a._odup.uk/TXT | NXDOMAIN | 13 | 643 | | _odup.a.uk/TXT | NODATA | 10 | 644 | | b._odup.a.uk/TXT | NODATA | 10 | 645 | | c.b._odup.a.uk/TXT | +org | 12 | 646 | | _odup.c.b.a.uk/TXT | -httpcookie | 14 | 647 | d.c.b.a.uk | _odup.uk/TXT | +bound -all | 10 | 648 | | a._odup.uk/TXT | NXDOMAIN | 13 | 649 | | _odup.a.uk/TXT | NODATA | 10 | 650 | | b._odup.a.uk/TXT | NODATA | 10 | 651 | | c.b._odup.a.uk/TXT | +org | 12 | 652 | | _odup.c.b.a.uk/TXT | -httpcookie | 10 | 653 | | d._odup.c.b.a.uk/TXT | NXDOMAIN | 14 | 654 | e.a.uk | _odup.uk/TXT | +bound -all | 10 | 655 | | a._odup.uk/TXT | NXDOMAIN | 13 | 656 | | _odup.a.uk/TXT | NODATA | 10 | 657 | | e._odup.a.uk/TXT | -httpcookie | 14 | 658 | f.e.a.uk | _odup.uk/TXT | +bound -all | 10 | 659 | | a._odup.uk/TXT | NXDOMAIN | 13 | 660 | | _odup.a.uk/TXT | NODATA | 10 | 661 | | e._odup.a.uk/TXT | -httpcookie | 10 | 662 | | f.e._odup.a.uk/TXT | NXDOMAIN | 14 | 663 | co.uk | _odup.uk/TXT | +bound -all | 10 | 664 | | co._odup.uk/TXT | +bound -all | 14 | 665 | g.co.uk | _odup.uk/TXT | +bound -all | 10 | 666 | | co._odup.uk/TXT | +bound -all | 10 | 667 | | g.co._odup.uk/TXT | NXDOMAIN | 13 | 668 | | _odup.g.co.uk/TXT | NXDOMAIN | 11 | 669 | ck | _odup.ck/TXT | +bound -all | 14 | 670 | h.ck | _odup.ck/TXT | +bound -all | 10 | 671 | | h._odup.ck/TXT | +bound:0 -all | 14 | 672 | i.h.ck | _odup.ck/TXT | +bound -all | 10 | 673 | | h._odup.ck/TXT | +bound:0 -all | 13 | 674 | | _odup.i.h.ck/TXT | NXDOMAIN | 11 | 675 | www.ck | _odup.ck/TXT | +bound -all | 10 | 676 | | www._odup.ck/TXT | +org | 12 | 677 | | _odup.www.ck/TXT | NXDOMAIN | 11 | 678 +-------------+----------------------+---------------+------+ 680 The sequence of queries, responses, and corresponding steps (i.e., 681 from Section 4) followed for ODUP resolution of each name. The 682 version information (i.e., "v=odup1") has been stripped from the 683 policy for readability. 685 Table 2: DNS Queries for ODUP Resolution Examples 687 +-------------+-----------+-----------+-----------------------------+ 688 | Domain Name | Org. | Policy | Policy ([D]efault, | 689 | | Domain | Domain | [E]xplicit, [I]nherited) | 690 +-------------+-----------+-----------+-----------------------------+ 691 | uk. | uk. | uk. | -all (E) | 692 | a.uk. | a.uk. | a.uk. | +all (D) | 693 | b.a.uk. | a.uk. | a.uk. | +all (I) | 694 | c.b.a.uk. | c.b.a.uk. | c.b.a.uk. | -httpcookie +all (E) | 695 | d.c.b.a.uk. | c.b.a.uk. | c.b.a.uk. | -httpcookie +all (I) | 696 | e.a.uk. | a.uk. | e.a.uk. | -httpcookie +all (E) | 697 | f.e.a.uk. | a.uk. | e.a.uk. | -httpcookie +all (I) | 698 | co.uk. | uk. | co.uk. | -all (I) | 699 | g.co.uk. | g.co.uk. | g.co.uk. | +all (D) | 700 | ck. | ck. | ck. | -all (E) | 701 | h.ck. | ck. | h.ck. | -all (I) | 702 | i.h.ck. | i.h.ck. | i.h.ck. | +all (D) | 703 | www.ck. | www.ck. | www.ck. | +all (D) | 704 +-------------+-----------+-----------+-----------------------------+ 706 Policies resulting from the ODUP names and corresponding statements 707 listed in Table 1 and illustrated in Figure 1. The version 708 information (i.e., "v=odup1") has been stripped from the policy for 709 readability. [D]efault policy means that there was no explicit 710 policy designated for the organization, so the default ("v=odup1 711 +all") is used. [E]xplicit policy means that a policy is defined for 712 the domain name in question. [I]nherited policy means that it is 713 inherited from the closest ancestor with default or explicit policy. 715 Table 3: Effective ODUP Policies 717 7. Example Application Use 719 While designating the manner in which ODUP is applied in applications 720 is beyond the scope of this document, for added clarity and utility, 721 we provide some examples of how it might be consumed, using the 722 examples data Section 6 for reference. 724 7.1. Public Suffix List Replacement 726 As mentioned in Section 5, the ODUP statements within the policy- 727 negative realm provide a drop-in replacement for the public suffix 728 list(s) from which they are initially derived. Whether used offline 729 (i.e., having been been downloaded and optionally converted to a 730 legacy list format) or learned through DNS queries, the applications 731 that previously used a public suffix list, can use the contents of 732 the _odup domain to achieve the same baseline behavior. That 733 includes HTTP cookie policy [RFC6265], identifying organizational 734 domains for DMARC [RFC7489], and other use. 736 Beyond this baseline behavior provided by installation of the policy- 737 negative realm, ODUP provides the opportunity for additional 738 functionality, described subsequently. 740 7.2. HTTP Cookies 742 [RFC6265] directs user agents to reject HTTP cookies whose Domain 743 attribute specifies a scope that does not include the origin server. 744 The origin server is within scope if its name is equal to or a 745 subdomain of the value of the Domain attribute. Basically, this 746 allows an origin server to set a cookie with a Domain attribute value 747 of any domain name in its ancestry (but below the public suffix 748 boundary). 750 With ODUP policy HTTP cookies can be built on organizational 751 boundaries, including not only the policy-negative realm, but also at 752 other designated points. For example, given the organizational 753 boundary between b.a.uk and c.b.a.uk, the origin server d.c.b.a.uk 754 can set a cookie for d.c.b.a.uk and c.b.a.uk, but not for b.a.uk. 755 Likewise, when a user-agent has a cookie with domain b.a.uk, it will 756 not send it when communicating with d.c.b.a.uk or c.b.a.uk because 757 organizational boundaries supercede "domain-matching" ([RFC6265]). 759 In addition, cookie policies between organizational boundaries can be 760 specified using the "httpcookie" directive. For example, neither 761 f.e.a.uk nor e.a.uk can be the value of the Domain attribute of an 762 HTTP cookie, even though they are not public suffixes. However, this 763 doesn't mean that user agents communicating with f.e.a.uk or e.a.uk 764 cannot set or return cookies for a.uk, so it is not particularly 765 useful, except within the policy-negative realm. 767 7.3. DMARC 769 Whereas [RFC7489] includes only provides a single possible 770 organizational domain for any given domain name, ODUP allows the 771 organizational domain to be specified, such that it can be designated 772 and identified from anywhere within the ancestral namespace. 774 8. Contributors 776 The namespace convention used for ODUP names resembles and was 777 inspired by that developed in [I-D.levine-orgboundary], for which we 778 acknowledge John Levine's efforts in this area. 780 9. IANA Considerations 782 This document contains no requests for IANA. 784 10. Security Considerations 786 Applications depending on the mechanisms herein described to learn 787 organizational domains and polices for domain names have their own 788 security considerations. We reference [RFC6265] and [RFC7489] as 789 examples of those. 791 Because the ODUP resolution mechanisms themselves rely on DNS queries 792 (and zone transfers and/or HTTP, for the policy-negative realm), its 793 security is only as secure as that of the underlying lookup/download 794 mechanisms themselves. DNSSEC and HTTPS can be useful in ensuring 795 authenticity of policy statements through the respective lookup 796 mechanisms. 798 The iterative query process utilized by ODUP resolution can be 799 potentially revealing of queries to higher DNS authorities, in part 800 because of the necessity of finding the longest matched ODUP names. 801 This is in contrast to the principles of minimum disclosure to 802 maximize DNS privacy. This is mitigated by stopping at NXDOMAIN 803 responses, as described in Section 4. Additionally, referencing a 804 locally downloaded version of the policy-negative realm for partial 805 or "sufficient" ODUP resolution, as suggested in Section 5 can reduce 806 queries to the _odup zone. 808 11. References 810 11.1. Normative References 812 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 813 Requirement Levels", BCP 14, RFC 2119, 814 DOI 10.17487/RFC2119, March 1997, 815 . 817 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 818 Resource Identifier (URI): Generic Syntax", STD 66, 819 RFC 3986, DOI 10.17487/RFC3986, January 2005, 820 . 822 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 823 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 824 . 826 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 827 Specifications: ABNF", STD 68, RFC 5234, 828 DOI 10.17487/RFC5234, January 2008, 829 . 831 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 832 DOI 10.17487/RFC6265, April 2011, 833 . 835 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 836 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 837 DOI 10.17487/RFC7231, June 2014, 838 . 840 11.2. Informative References 842 [I-D.levine-orgboundary] 843 Levine, J., "Publishing Organization Boundaries in the 844 DNS", draft-levine-orgboundary-02 (work in progress), July 845 2013. 847 [NewgTLDs] 848 ICANN, "New Generic Top-Level Domains", 2016, 849 . 851 [PSL] Mozilla Foundation, "Public Suffix List", 2016, 852 . 854 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 855 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 856 . 858 [RFC1035] Mockapetris, P., "Domain names - implementation and 859 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 860 November 1987, . 862 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 863 DOI 10.17487/RFC2818, May 2000, 864 . 866 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 867 Protocol (HTTP/1.1): Message Syntax and Routing", 868 RFC 7230, DOI 10.17487/RFC7230, June 2014, 869 . 871 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 872 Message Authentication, Reporting, and Conformance 873 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 874 . 876 Appendix A. Pseudo-code for ODUP Resolution 878 function resolveODUP(N = [l(n)...l(1)], orgBoundary) 879 { 880 Require: N = [l(n)...l(1)], n >= 1 881 (a sequence of labels representing domain name, N) 882 Require: orgBoundary, 1 <= orgBoundary <= n 883 (an integer representing an index into N) 884 Return: a three-tuple consisting of: 885 - policyDomain, the domain name from the which the policy 886 was derived 887 - orgDomain, the organizational domain of N 888 - policy, the raw policy resulting from TXT DNS queries 890 // orgDomain consists of labels 1 through orgBoundary 891 orgDomain := [l(orgBoundary)...l(1)] 893 subDomainLabels := n - orgBoundary 894 longestMatch := NULL 895 longestMatchBoundary := NULL 896 existingLabels := 0 897 for all i in [0...subDomainLabels] 898 { 899 if i = 0 900 { 901 subDomain := [] 902 } 903 else 904 { 905 subDomain := [l(orgBoundary + i)...l(orgBoundary + 1)] 906 } 907 testDomain := subDomain | ["_odup"] | orgDomain 908 queryResult := queryDNS(testDomain, TXT) 910 if queryResult is either NOERROR or NODATA AND i > 0 911 { 912 // Update existingLabels because the name exists. 913 // Only do this for labels other than _odup 914 // (hence the test for i > 0). 915 existingLabels := existingLabels + 1 916 } 918 if queryResult is an answer 919 { 920 // Update longestMatch by giving org and bound highest 921 // priority and ignoring policy statements below "bound". 922 if queryResult includes "+org" OR 923 queryResult includes "+bound" OR 924 longestMatch doesn't include "+bound" 925 { 926 longestMatch := queryResult 927 longestMatchBoundary := i 928 } 930 if queryResult includes "+org" 931 { 932 // If this was an organizational domain designation, 933 // then don't go any further; the organization will 934 // dictate policy 935 break 936 } 937 if queryResult includes "+bound" AND 938 was synthesized from wildcard 939 { 940 // If this was a boundary designation, and the answer 941 // was synthesized from a wildcard, no further 942 // lookups must be performed 943 break 944 } 945 } 946 else if queryResult is NXDOMAIN response 947 { 948 // An NXDOMAIN result means that no further lookups are 949 // necessary, as there is no subtree 950 break 951 } 952 } 954 if longestMatch is not NULL 955 { 956 // If a policy has been found, then look for +org or +bound 957 // directives, which will cause resolveODUP() to be called 958 // recursively. A +org directive indicates that the 959 // organizational domain and policy are (at least) one level 960 // lower than the value of longestMatchBoundary. 961 if longestMatch includes "+org" 962 { 963 return 964 resolveODUP(N, orgBoundary + longestMatchBoundary) 965 } 966 // A +bound directive indicates that the organizational domain 967 // and policy are (at least) one level lower than the value of 968 // existingLabels. 969 else if longestMatch includes "+bound" AND 970 orgBoundary + existingLabels <= n 971 { 972 return resolveODUP(N, orgBoundary + existingLabels) 973 } 974 } 976 // With no +org or +bound directives present, the orgDomain and 977 // policy remain as they were looked up, and are returned with 978 // the policy domain 979 return [l(orgBoundary + longestMatchBoundary)...l(1)], 980 orgDomain, longestMatch 981 } 983 // Return an empty policy 984 return orgDomain, orgDomain, "" 986 } 988 Author's Address 990 Casey Deccio 991 Verisign Labs 992 12061 Bluemont Way 993 Reston, VA 20190 994 USA 996 Phone: +1 703-948-3200 997 Email: cdeccio@verisign.com