idnits 2.17.1 draft-deccio-dbound-name-relationships-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2015) is 3207 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2965 (Obsoleted by RFC 6265) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 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 J. Levine 5 Expires: January 7, 2016 Taughannock Networks 6 July 6, 2015 8 Concepts for Domain Name Relationships 9 draft-deccio-dbound-name-relationships-00 11 Abstract 13 Various Internet protocols and applications require some mechanism 14 for identifying relationships between Domain Name System (DNS) names. 15 In this document we provide examples of protocols and applications 16 for which knowledge of these relationships is useful, if not 17 required. Further we discuss the various types of domain name 18 relationships, review current needs and solutions, and identify 19 considerations for solution sets. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 7, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Domain Name Concepts . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Domain Names . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. Domain Name Scope . . . . . . . . . . . . . . . . . . . . 4 59 2.2.1. Public/private Boundaries . . . . . . . . . . . . . . 4 60 2.3. Domain Name Relationships . . . . . . . . . . . . . . . . 4 61 3. Policy-based Domain Name Relationships . . . . . . . . . . . . 5 62 3.1. Cross-Scope Policy Relationships . . . . . . . . . . . . . 5 63 3.2. Intra-Scope Policy Relationships . . . . . . . . . . . . . 5 64 3.2.1. Public-public Policy Relationships . . . . . . . . . . 6 65 3.2.2. Private-private Policy Relationships . . . . . . . . . 6 66 4. Known Applications Requiring Identification of 67 Policy-based Domain Relationships . . . . . . . . . . . . . . 6 68 4.1. HTTP Cookies . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.2. Email sender verification . . . . . . . . . . . . . . . . 7 70 4.3. SSL certificate requests . . . . . . . . . . . . . . . . . 7 71 5. Public Suffix List . . . . . . . . . . . . . . . . . . . . . . 8 72 5.1. Known Application Usage . . . . . . . . . . . . . . . . . 9 73 6. Solution Considerations . . . . . . . . . . . . . . . . . . . 9 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 9. Informative References . . . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction 81 The use of various Internet protocols and applications has introduced 82 the desire and need for designated relationships between Domain Name 83 System (DNS) names, beyond the lineal relationship inherent in the 84 names themselves. While protocols, such as that used by HTTP 85 Cookies, have traditionally used ancestral relationships to determine 86 allowable scope of information sharing and authorization, there is an 87 increasing need to identify relationships between arbitrary domains. 89 We begin by establishing terminology and concepts, after which we 90 discuss known applications for which the identification of domain 91 name relationships are desirable or required. We then discuss the 92 Public Suffix List, the primary solution for domain relationships 93 currently available. Finally, we recommend considerations for 94 solutions in this problem space. 96 2. Domain Name Concepts 98 For consistency in language we define terms and concepts surrounding 99 domain names. 101 2.1. Domain Names 103 A DNS domain name is represented as sequence of dot-separated labels, 104 such as www.example.com (i.e., comprised of labels "www", "example", 105 and "com"). This sequence corresponds to the list of the labels 106 formed by traversing the tree representing the domain name space, 107 from the node representing the name itself to the root (top) of the 108 tree ([RFC1034]). In this tree context, we thus refer to domain 109 name's parent as the domain name formed by removing the leftmost 110 label (i.e., the domain name corresponding to the node directly above 111 it in the tree). The parent of www.example.com is example.com. 113 As there are no requirements or inferences surrounding delegation 114 (i.e., zone cut) at any point in the DNS tree, there are no 115 assumptions in this document about administrative boundaries drawn by 116 delegations, unless explicitly stated otherwise. That is to say that 117 this document considers DNS names independently from their 118 administration, as defined by the DNS. 120 As noted in [RFC1034], the term "domain name" is used in contexts 121 outside the DNS. The scope of this document is limited to domain 122 names as defined by the DNS. 124 2.2. Domain Name Scope 126 The use of domain names in various applications over time has 127 produced a notion of scope, which we use to refer to the general 128 ability of arbitrary entities to register children of a domain name 129 (i.e., create child nodes in the domain name tree). In some contexts 130 these are called "public suffixes" or "registry controlled domains" 131 ([RFC6265]). For example, children of the top-level domain (TLD) 132 com, are generally registrable by arbitrary entities, which puts the 133 com domain name in the public scope. However, com's children are 134 typically not used in the same fashion (though certainly there are 135 exceptions), which puts them largely in the private scope. 137 The children of public domain names may either be in public or 138 private scope; likewise the children of private domain names may 139 either be in public or private scope. 141 While zone cuts often exist along public/private scope boundaries 142 (e.g., between com and example.com), they are not required at these 143 boundaries, nor are scope boundaries required at zone cuts. In this 144 document public/private scope is considered independent of 145 administrative boundaries defined by the DNS (i.e., zone cuts). 147 The most well-known delineator of public/private scope is the Public 148 Suffix List (PSL) [PSL], which is described later in this document. 150 2.2.1. Public/private Boundaries 152 If we consider the root domain name itself to be public, then between 153 the root domain name and any private domain name (below), there must 154 exist at least one boundary going from some public parent to private 155 child. The first such boundary encountered upon downward traversal 156 from the root is the first-level public boundary. Subsequent public- 157 to-private boundaries are referred to as lower-level public 158 boundaries. For example, because the com domain name is considered 159 public, if we assume that example.com is private, then the first- 160 level public boundary is between com and example.com. If the 161 public.example.com domain name is considered public (i.e., children 162 domain names can be registered by arbitrary third parties) and 163 foo.public.example.com is a private domain name, then a lower-level 164 public boundary exists between public.example.com and 165 foo.public.example.com. 167 2.3. Domain Name Relationships 169 In this document two types of domain name relationships are 170 identified: ancestry and policy. An ancestral relationship exists 171 between two domains if one domain name is an ancestor of the other. 173 A policy relationship exists between two domain names if their 174 relationship is such that application policy should treat them as 175 equivalent. For example, the two names might be administered by the 176 operating organization, or there might business or other 177 relationships between the two operating entities. 179 In the simplest case, two domain names might be policy-related for 180 all applications or purposes. However, it is possible that two 181 domains are related only for explicitly defined purposes. 183 An ancestral relationship between two names can be identified merely 184 by comparing the names themselves to determine whether one is a 185 substring of the other. However, there is no inherent way to 186 determine policy relationships neither by examination of the names 187 themselves, nor by examining the administrative boundaries (i.e., 188 zone cuts) defined in the DNS. This is the problem being considered 189 in this document. 191 3. Policy-based Domain Name Relationships 193 Because policy-based domain name relationships are not inherently 194 apparent based on the names themselves or DNS protocol, mechanisms 195 outside the DNS namespace and base protocol are necessary to 196 advertise and detect those relationships. 198 In this section we enumerate the different types of ancestral and 199 scope relationships upon which policy-based relationships can be 200 overlaid. 202 3.1. Cross-Scope Policy Relationships 204 If scope of one domain name is public and another is private, then it 205 can be inferred, by the definition of their respective scopes, that 206 there exists no policy-based relationship between the two. That is, 207 a public domain name cannot be related, for policy purposes, to a 208 private domain name. 210 Note that this doesn't prohibit policy relationships between two 211 domain names of the same scope but having (an even number) of scope 212 boundaries in between. 214 3.2. Intra-Scope Policy Relationships 216 We now consider the existence of a policy relationship between two 217 domains names of the same scope. 219 3.2.1. Public-public Policy Relationships 221 The connotation of a public domain name in the context of policy is 222 that it should not be used for purposes normally associated with 223 private domain names. For example, it would be unreasonable to 224 expect legitimate mail to come from an email address having the exact 225 suffix of org.au (a domain name currently identified by [PSL] as 226 being public). This is especially true of domain names above the 227 first-level public boundary. 229 Because of this connotation, one consideration for policy amongst two 230 domain names, both public, is that no effective relationship exists 231 because they are ineligible by definition. Other than that, there is 232 insufficient information from only domain names and scope alone to 233 confirm or deny a policy relationship. 235 3.2.2. Private-private Policy Relationships 237 There are two classes of potential private-private policy 238 relationships: ancestral and cross-domain (non-ancestral). In 239 neither case can the presence or absence of a policy relationship be 240 confirmed using only the names and scope information. 242 4. Known Applications Requiring Identification of Policy-based Domain 243 Relationships 245 In this section we discuss the current state of known applications 246 requiring identification of policy-based domain name relationships. 248 4.1. HTTP Cookies 250 Domain names are used extensively in conjunction with the Hypertext 251 Transfer Protocol (HTTP) ([RFC7230], [RFC7231]). The domain names 252 used in Uniform Resource Identifiers (URIs) [RFC3986] are used by 253 HTTP clients not only for resolution to an HTTP server Internet 254 Protocol (IP) address, but also for enforcing policy. 256 HTTP clients maintain local state in the form of key/value pairs 257 known as cookies ([RFC6265]). While most often cookies are initially 258 set by HTTP servers, HTTP clients send all cookies in HTTP requests 259 for which the domain name in the URI is within the cookies' scope. 260 The scope of a cookie is defined using a domain name in the "domain" 261 attribute of the cookie. When a cookie's "domain" attribute is 262 specified as a domain name (as opposed to an IP address), the domain 263 name in the URL is considered within scope if it is a descendant of 264 the "domain" attribute. 266 RFC 2965 [RFC2965] (now obsolete) required that the value of the 267 "domain" field carry at least one embedded dot. This was to prohibit 268 TLDs--which were almost exclusively public--from being associated, by 269 policy, with other domains. Cookies having public scope would enable 270 the association of HTTP requests across different, independently 271 operated domains, which policy association raises concerns of user 272 privacy and security. 274 In the current specification ([RFC6265]), the semantic requirements 275 were modified to match "public suffixes" because it was recognized 276 that TLDs are not the only domain names with public scope--and that 277 not all TLDs are public suffixes. The notion that all TLDs are 278 inherently public has been challenged by the many and diverse domain 279 names that have been delegated since 2013 as part of the new generic 280 top-level domain (gTLD) program ([NewgTLDs]). 282 4.2. Email sender verification 284 An emerging sender verification called Domain-based Message 285 Authentication, Reporting and Conformance (DMARC) 286 [I-D.kucherawy-dmarc-base] attempts to validate the domain name of 287 the author's address on the message's "From:" header using the 288 DomainKeys Identified Email (DKIM) [RFC5585] and Sender Policy 289 Framework (SPF) [RFC7208] authentication schemes. A DKIM signature 290 and SPF check each validate a specific domain name. For DKIM it is 291 the domain name corresponding the DKIM signature. For SPF the domain 292 name of the message's bounce address is validated. DMARC allows 293 approximate matching between the author's domain and the validated 294 domain name, where one can be an ancestor or descendant of the other. 296 DMARC validators are supposed to ensure that the two domain names are 297 under the same management, the specifics of which are deliberately 298 left out of the spec. 300 4.3. SSL certificate requests 302 Secure Socket Layer (SSL) certificate authorities typically validate 303 certificate signing requests by sending a confirmation message to one 304 of the WHOIS contacts for the (private scope) domain name (CA/B 305 Ballot 74 [CA/B-Ballot-74]). In cases where there are multiple 306 levels of delegation (i.e., crossing public/private scopes), the 307 WHOIS contact needs to be the one for the registrant of the domain, 308 not a higher level registration. 310 When an SSL certificate is for a wildcard domain name, the entire 311 range of names covered by the wildcard needs to be under the same 312 control. Authorities do not (knowingly) issue certificates for 313 public domain names such as *.org.au. 315 5. Public Suffix List 317 The most well-known resource currently available for identifying 318 public domain names is the Public Suffix List (PSL) [PSL]. The PSL 319 is explicitly referenced as an example of an up-to-date public suffix 320 list in [RFC6265]. The PSL was developed by Mozilla Firefox 321 developers to further address HTTP security and privacy concerns 322 surrounding cookie scope when the "no embedded dot" rule of [RFC2965] 323 was the upper limit. 325 The PSL contains a list of known public suffixes, and includes 326 placeholder public domains designated by "wildcard" notation in the 327 file. A wildcard implies that all children of the wildcard's parent 328 are in fact public domain names themselves--except where otherwise 329 noted as a wildcard exception. For example, we use the contrived 330 entries in Table 1 to demonstrate this use of the PSL. 332 +--------------+------------------------------------+ 333 | Entry | Meaning | 334 +--------------+------------------------------------+ 335 | example | example is public | 336 | *.example | All children of example are public | 337 | !foo.example | foo.example is private | 338 +--------------+------------------------------------+ 340 Table 1: Contrived PSL Entries 342 These entries result in the scopes shown in Table 2: 344 +---------------------+---------+ 345 | Name | Scope | 346 +---------------------+---------+ 347 | example | Public | 348 | foo.example | Private | 349 | baz.foo.example | Private | 350 | bar.example | Public | 351 | baz.bar.example | Private | 352 | www.baz.bar.example | Private | 353 +---------------------+---------+ 355 Domain name scope based on the PSL entries from Table 1. 357 Table 2: Contrived PSL Entries 359 The PSL effectively identifies scope, insomuch as the list is 360 accurate. Of the 6,823 entries in the PSL at the time of this 361 writing, all but 50 are used to designate first-level public 362 boundaries; the remainder designate lower-level boundaries. The 363 primary function of the PSL, therefore, is to delineate first-level 364 public boundaries. 366 Matters of policy that can be settled simply by identifying the scope 367 of the names in question are thus addressed by the PSL. However, the 368 question of determining whether a policy-based relationship between 369 intra-scope names (with the possible exception of those of public 370 scope) are unaddressed. 372 5.1. Known Application Usage 374 The PSL is used by several browsers, including Mozilla Firefox, to 375 identify domain names as public or private. This is used for 376 validating the domain attribute of cookies. Additionally, it 377 provides visual and organizational convenience for readily 378 identifying the highest intra-scope private ancestor for a given 379 private domain name (i.e., the child of the domain name's nearest 380 public ancestor). This is useful for organizing names and URIs by 381 domain name, as in bookmarks, and for highlighting key parts of URIs 382 or certificates in the address bar or other parts of the browser 383 interface. 385 Existing DMARC implementations are known to use the PSL to assert 386 policy-based relationships between SPF- or DKIM-authenticated 387 validated domain names and domain name corresponding to the address 388 in the "From:" header. Such a relationship is identified if two 389 domain names are both of private scope and share an ancestral 390 relationship. 392 DMARC implementations also use the PSL to identify the highest intra- 393 scope ancestor of a (private) domain name for the purpose of looking 394 up the DMARC DNS record. The the appropriate ancestor name is 395 identified it is appended to the label "_dmarc" to find the 396 appropriate information in the DNS. 398 SSL certificate authorities use the PSL to ensure that wildcards are 399 not issued for domain names having public scope. 401 6. Solution Considerations 403 The problem discussed in this document is the association of domain 404 names for policy purposes. The PSL has been the de-facto 405 supplementary resource utilized for identifying such relationships. 406 The shortcomings of only having domain names and their scope (e.g., 407 via the PSL) have been treated in Section Section 5. 409 An alternate paradigm for addressing the problem involves a system 410 wherein policy-based relationships are explicitly defined on a per- 411 domain name (pair) basis. For scalability and dynamic response this 412 is most effectively achieved through defining these relationships in 413 the DNS itself, e.g., through special records included in the DNS at 414 (or near) the domain names themselves, such as the mechanism proposed 415 in [I-D.sullivan-domain-origin-assert]. One benefit to this paradigm 416 is that it allows the definition of policy-based relationships 417 between arbitrary names at any locations in the DNS domain name tree, 418 and the notion of scope becomes moot. Another benefit is that it 419 puts the definition of those relationships in the hands of the 420 administrators and operators of the domain names themselves, rather 421 than a third party. 423 There are several challenges with the domain name-centric paradigm as 424 well. One challenge is that it requires correct, consistent, and 425 coordinated efforts by affected domain name operators. The number of 426 involved parties, moving parts, and dependencies introduces more 427 chance for error. Additionally, having the information available 428 online (e.g., in the DNS) means that consumption by local 429 applications is dependent on real-time Internet connectivity, which 430 is not always possible nor desirable. 432 Another solution set is that which includes both a scope definition 433 resource (e.g., the PSL) and a mechanism for explicit definition of 434 policy-based relationships on a per-domain name basis. In this case 435 the scope definitions are consulted first to determine whether a 436 policy-based relationship is possible, after which (if necessary) 437 special domain name-specific lookups are issued to further determine 438 whether such a relationship exists. This addresses what might be the 439 most common issues using a central, relatively simple, and 440 established mechanism, leaving the flexibility for additional 441 extensibility with domain name-specific relationship definitions. 443 We recommend that the cost and the value of the different solution 444 paradigms be considered when developing solutions for the problem of 445 defining policy-based relationships between domain names. As part of 446 this, the model of domain name relationships outlined in Section 447 Section 2.3 should be analyzed to consider which types of 448 relationships are most in demand, and which solutions are sufficient 449 for the circumstances in highest demand. Such will enable an 450 appropriate and usable balance of efficiency, robustness, 451 flexibility, and autonomy. 453 7. IANA Considerations 455 This document includes no requests for IANA. 457 8. Security Considerations 459 This document does not specify a protocol or usage and, therefore, 460 there are no new security considerations for it. There are security 461 considerations for major cases in which domain boundaries are used, 462 such as HTTP Cookies and DMARC, both discussed here. See the 463 Security Considerations of RFC 6265 [RFC6265] and 464 [I-D.kucherawy-dmarc-base]. 466 9. Informative References 468 [CA/B-Ballot-74] 469 Certificate Authority(CA)/Browser Forum, "Ballot 74", 470 2015, . 474 [I-D.kucherawy-dmarc-base] 475 Kucherawy, M. and E. Zwicky, "Domain-based Message 476 Authentication, Reporting and Conformance (DMARC)", 477 draft-kucherawy-dmarc-base-13 (work in progress), 478 February 2015. 480 [I-D.sullivan-domain-origin-assert] 481 Sullivan, A., "Asserting DNS Administrative Boundaries 482 Within DNS Zones", draft-sullivan-domain-origin-assert-02 483 (work in progress), October 2012. 485 [NewgTLDs] 486 ICANN, "New Generic Top-Level Domains", 2015, 487 . 489 [PSL] Mozilla Foundation, "Public Suffix List", 2015, 490 . 492 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 493 STD 13, RFC 1034, November 1987. 495 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 496 Mechanism", RFC 2965, October 2000. 498 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 499 Resource Identifier (URI): Generic Syntax", STD 66, 500 RFC 3986, January 2005. 502 [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 503 Identified Mail (DKIM) Service Overview", RFC 5585, 504 July 2009. 506 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 507 April 2011. 509 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 510 Authorizing Use of Domains in Email, Version 1", RFC 7208, 511 April 2014. 513 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 514 (HTTP/1.1): Message Syntax and Routing", RFC 7230, 515 June 2014. 517 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 518 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 520 Authors' Addresses 522 Casey Deccio 523 Verisign Labs 524 12061 Bluemont Way 525 Reston, VA 20190 526 USA 528 Phone: +1 703-948-3200 529 Email: cdeccio@verisign.com 531 John Levine 532 Taughannock Networks 533 PO Box 727 534 Trumansburg, NY 14886 536 Phone: +1 831 480 2300 537 Email: standards@taugh.com 538 URI: http://jl.ly