idnits 2.17.1 draft-sullivan-dbound-problem-statement-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 18, 2016) is 2962 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-13) exists of draft-kucherawy-dmarc-base-00 == Outdated reference: A later version (-10) exists of draft-pettersen-subtld-structure-09 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DBOUND A. Sullivan 3 Internet-Draft Dyn, Inc. 4 Intended status: Standards Track J. Hodges 5 Expires: August 21, 2016 PayPal 6 J. Levine 7 Taughannock Networks 8 February 18, 2016 10 DBOUND: DNS Administrative Boundaries Problem Statement 11 draft-sullivan-dbound-problem-statement-02 13 Abstract 15 Some Internet client entities on the Internet make inferences about 16 the administrative relationships among services on the Internet based 17 on the domain names at which they are offered. At present, it is not 18 possible to ascertain organizational administrative boundaries in the 19 DNS, therefore such inferences can be erroneous in various ways. 20 Mitigation strategies deployed so far will not scale. This memo 21 outlines what issues are to be addressed. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 21, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Prerequisites, Terminology, and Organization of this Memo . . 2 58 2. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 59 3. For the Use Case, Must an Ancestor Impose Policy? . . . . . . 5 60 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 64 8. Informative References . . . . . . . . . . . . . . . . . . . 8 65 Appendix A. Discussion Venue . . . . . . . . . . . . . . . . . . 10 66 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Prerequisites, Terminology, and Organization of this Memo 71 The reader is assumed to be familiar with the DNS ([RFC1034] 72 [RFC1035]) and the Domain Name System Security Extensions (DNSSEC) 73 ([RFC4033] [RFC4034] [RFC4035] [RFC5155]). 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC 2119 [RFC2119]. 79 To begin, Section 2 describes introduces the problem space and 80 motivations for this work. Then, Section 4 discusses the cases where 81 a there are needs for discerning administrative boundaries in the DNS 82 domain name space. 84 2. Introduction and Motivation 86 Many Internet resources and services, especially at the application 87 layer, are identified primarily by DNS domain names [RFC1034]. As a 88 result, domain names have become fundamental elements in building 89 security policies and also in affecting user agent behaviour. 91 For example, domain names are used for defining the scope of HTTP 92 state management "cookies" [RFC6265]. In addition there is a user 93 interface convention that purports to display an "actual domain name" 94 differently from other parts of a fully-qualified domain name, in an 95 effort to decrease the success of phishing attacks. In this 96 strategy, for instance, a domain name like 97 "www.bank.example.com.attackersite.tld" is formatted to highlight 98 that the actual domain name ends in "attackersite.tld", in the hope 99 of reducing user's potential impression of visiting 100 "www.bank.example.com". 102 Issuers of X.509 certificates make judgements about administrative 103 boundaries around domains when issuing the certificates. For some 104 discussion of the relationship between domain names and X.509 105 certificates, see [RFC6125]. 107 We can call the interpretation of domain names for these security 108 policies a domain-use rule. The simplest rule, and the one most 109 likely to work, is to treat each different domain name distinctly. 110 Under this approach, foo.example.org, bar.example.org, and 111 baz.example.org are all just different domains. Unfortunately, this 112 approach is too naive to be useful. Often, the real control over 113 domain names is the same in several names (in this example, 114 example.org and its children). Therefore, clients have attempted to 115 make more sophisticated rules around some idea of such shared 116 control. We call such an area of shared control a "policy realm", 117 and the control held by the administrator of policy realm the "policy 118 authority". 120 Historically, rules were sometimes based on the DNS tree. Early 121 rules made a firm distinction between top-level domains and 122 everything else; but this was also too naive, and later attempts were 123 based on inferences from the domain names themselves. That did not 124 work well, because there is no way in the DNS to discover the 125 boundaries of policy realms. 127 Some have attempted to use the boundary of zone cuts (i.e. the 128 location of the zone's apex, which is at the SOA record; see 129 [RFC1034] and [RFC1035]). That boundary is neither necessary nor 130 sufficient for these purposes: it is possible for a large site to 131 have many, administratively distinct subdomain-named sites without 132 inserting an SOA record, and it is also possible that an 133 administrative entity (like a company) might divide its domain up 134 into different zones for administrative reasons unrelated to the 135 names in that domain. It was also, prior to the advent of DNSSEC, 136 difficult to find zone cuts. Regardless, the location of a zone cut 137 is an administrative matter to do with the operation of the DNS 138 itself, and not useful for determining relationships among policy 139 realms. 141 The different uses of domain names and their related issues often 142 appear to be different kinds of problems. The issue of whether two 143 names may set cookies for one another appears to be a different 144 matter from whether two names get the same highlighting in a 145 browser's address bar, or whether a particular name "owns" all the 146 names underneath it. But the problems all boil down to the same 147 fundamental problem, which is that of determining whether two 148 different names in the DNS are under the control of the same entity 149 and ought to be treated as having an important administrative 150 relationship to one another. 152 What appears to be needed is a mechanism to determine policy realm 153 boundaries in the DNS. That is, given two domain names, one needs to 154 be able to answer whether the first and the second are either within 155 the same policy realm or have policy realms that are related in some 156 way. We may suppose that, if this information were to be available, 157 it would be possible to make useful decisions based on the 158 information. 160 A particularly important distinction for security purposes has been 161 the one between names that are mostly used to contain other domains, 162 as compared to those that are mostly used to operate services. The 163 former are often "delegation-centric" domains, delegating parts of 164 their name space to others, and are frequently called "public suffix" 165 domains or "effective TLDs". The term "public suffix" comes from a 166 site, [publicsuffix.org], that publishes a list of domains -- which 167 is also known as the "effective TLD (eTLD) list", and henceforth in 168 this memo as the "public suffix list" -- that are used to contain 169 other domains. Not all, but most, delegation-centric domains are 170 public suffix domains; and not all public suffix domains need to do 171 DNS delegation, although most of them do. The reason for the public 172 suffix list is to make the distinction between names that must never 173 be treated as being in the same policy realm as another, and those 174 that might be so treated. For instance, if "com" is on the public 175 suffix list, that means that "example.com" lies in a policy realm 176 distinct from that of com. 178 Unfortunately, the public suffix list has several inherent 179 limitations. To begin with, it is a list that is separately 180 maintained from the list of DNS delegations. As a result, the data 181 in the public suffix list can diverge from the actual use of the DNS. 182 Second, because its semantics are not the same as those of the DNS, 183 it does not capture unusual features of the DNS that are a 184 consequence of its structure (see [RFC1034] for background on that 185 structure). Third, as the size of the root zone grows, keeping the 186 list both accurate and synchronized with the expanding services will 187 become difficult and unreliable. Perhaps most importantly, it puts 188 the power of assertion about the operational policies of a domain 189 outside the control of the operators of that domain, and in the 190 control of a third party possibly unrelated to those operators. 192 There have been suggestions for improvements of the public suffix 193 list, most notably in [I-D.pettersen-subtld-structure]. It is 194 unclear the extent to which those improvements would help, because 195 they represent improvements on the fundamental mechanism of keeping 196 metadata about the DNS tree apart from the DNS tree itself. 198 Moreover, it is not entirely plain that the public/private 199 distinction is really the best framework with which to understand the 200 problem. It is plain that any solution that emerges will need, to be 201 useful, to provide a way of making the public/private distinction, 202 since so much deployed software relies on that distinction. It seems 203 possible, however, that greater nuance would provide distinctions 204 that are currently desired but cannot be supported using the public 205 suffix list. The best way to figure this out is to enumerate known 206 problems and see whether there is something common underlying them 207 all, or whether the different problems might at least be grouped into 208 a few common cases. 210 3. For the Use Case, Must an Ancestor Impose Policy? 212 It is possible to identify two common policy patterns into which 213 practical uses fall. One is a positive policy that will necessarily 214 be imposed by an ancestor in case a policy for the owner name itself 215 is not available. The other is a policy that need not get inherited 216 from an ancestor. Negative assertions by an ancestor (i.e. that a 217 descendent does not share a policy realm) fall into this category, 218 because the descendent does not have a positive policy imposed. 220 The first pattern we may call the inheritance type. In this use 221 pattern, a client attempting to identify a policy that applies at a 222 given name will use a policy found at a name closer to the root of 223 the DNS, if need be. This approach is useful when a client must have 224 some kind of policy in order to continue processing. Because the DNS 225 is a hierarchical name system, it is always possible for a 226 subordinate name to be permitted only in case the superordinate 227 policies are followed. 229 The second pattern we may call the orphan type. In this use pattern, 230 if a policy at a name is not specifically offered then it is better 231 to assume there is a null policy than to infer some inherited policy. 232 Note that orphan names might be related to other names (which makes 233 the term somewhat unfortunate). Rather, in these cases policy is 234 assumed to be unshared unless there is evidence otherwise. [[CREF1: 235 Probably something better than "orphan" would be good, but I can't 236 think of a better name. --ajs@anvilwalrusden.com]] 238 The choice of which pattern is preferable depends largely on what the 239 use of a policy seeks to achieve. Some uses of policy require 240 determination of commonality among domains; in such cases, the 241 inheritance pattern may be needed. Other uses are attempts to 242 identify differences between domains; in such cases, the orphan 243 pattern is useful. 245 The public suffix list provides a starting point for both patterns, 246 but is neither necessary nor sufficient for either case. Where the 247 inheritance pattern is used, the public suffix list provides a 248 minimal starting point whence inheritance can start. Where the 249 orphan pattern is used, the public suffix list provides the exclusion 250 needed, but cannot provide either evidence that the list is up to 251 date nor evidence that two owner names reside in the same policy 252 realm. 254 4. Use Cases 256 This section outlines some questions and identifies some known use 257 cases of the public suffix list. 259 HTTP state management cookies The mechanism can be used to determine 260 the scope for data sharing of HTTP state management cookies 261 [RFC6265]. Using this mechanism, it is possible to determine 262 whether a service at one name may be permitted to set a cookie for 263 a service at a different name. (Other protocols use cookies, too, 264 and those approaches could benefit similarly.) An application has 265 to answer in this case the question, "Should I accept a cookie for 266 domain X from the domain Y I am currently visiting?" 268 User interface indicators User interfaces sometimes attempt to 269 indicate the "real" domain name in a given domain name. A common 270 use is to highlight the portion of the domain name believed to be 271 the "real" name -- usually the rightmost three or four labels in a 272 domain name string. An application has to answer in this case the 273 question, "What domain name is relevant to show the user in this 274 case?" The answer to this must be some portion of the domain name 275 being displayed, but it is user- and context-sensitive. 277 Setting the document.domain property The DOM same-origin policy 278 might be helped by being able to identify a common policy realm. 279 An application has to answer in this case the question, "Is domain 280 X under the same control as domain Y?" It's worth noting that, in 281 this case, neither X nor Y need be actually visible to a user. 283 Email authentication mechanisms Mail authentication mechanisms such 284 as DMARC [I-D.kucherawy-dmarc-base] need to be able to find policy 285 documents for a given domain name given a subdomain. An 286 application performing DMARC processing must answer the question, 287 "Given the domain X currently being evaluated, where in the DNS is 288 the DMARC record?" DMARC depends on the DNS hierarchical 289 relationship, and unlike some other cases wants to find the DMARC 290 record that is closest to the root zone. 292 SSL and TLS certificates Certificate authorities need to be able to 293 discover delegation-centric domains in order to avoid issuance of 294 certificates at or above those domains. There are two cases: 296 * A certificate authority must answer the question, "Should I 297 sign a certificate at this domain name given the request before 298 me?" 300 * A certificate authority must answer the question, "Should I 301 sign a certificate for a wildcard at this domain name?" 303 [[CREF2: There is another case here, noted by Jeffrey Walton, 304 about "verifying the end-entity certificate issued by an 305 organizational subordinate CA *without* constraints." I didn't 306 understand the issue well enough to write the text here. 307 --ajs@anvilwalrusden.com]] 309 HSTS and Public Key Pinning with 310 includeSubDomains flag set 311 Clients that are using HSTS and public key pinning using 312 includeSubDomains need to be able to determine whether a subdomain 313 is properly within the policy realm of the parent. An application 314 performing this operation must answer the question, "Should I 315 accept the rules for using X as valid for Y.X?" 317 Linking domains together for merging 318 operations 319 It is frequently the case that domain names are aliases for one 320 another. Sometimes this is because of an ongoing merger (as when 321 one company takes over another and merges operations). A client 322 encountering such a site needs to answer the question, "Is domain 323 X just another name for domain Y?" 325 Linking domains together for reporting 326 purposes 327 An application that wants to categorize domains for the purposes 328 of reporting must answer the question, "Are these two names 329 versions of each other for the purposes of reporting statistics?" 331 DMARC science fiction use case DMARC's current use of the PSL is to 332 determine the 'Organizational Domain'.. for use when discovering 333 DMARC policy records. PSL works well enough for production 334 environments in today's world. However, after hearing about 335 cross-domain requirements of cookies and cross-domain security use 336 cases in the browser, it strikes me that any functionality (policy 337 authority?) that allows domains to be linked would be incredibly 338 useful in the DMARC world, too. DMARC?s requirement for 339 Identifier Alignment between SPF-authenticated domain, DKIM 340 d=domain, and a message?s From: domain could be relaxed to include 341 domains that were somehow associated via a policy authority. This 342 capability would be *very* nice to have at hand. 344 5. Security Considerations 346 A mechanism that satisfied the needs outline above would enable 347 publication of assertions about administrative relationships of 348 different DNS-named systems on the Internet. If such assertions were 349 to be accepted without checking that both sides agree to the 350 assertion, it would be possible for one site to become an 351 illegitimate source for data to be consumed in some other site. In 352 general, positive assertions about another name should never be 353 accepted without querying the other name for agreement. 355 Undertaking any of the inferences suggested in this draft without the 356 use of the DNS Security Extensions exposes the user to the 357 possibility of forged DNS responses. 359 This memo does not actually specify any mechanisms, so it raises no 360 security considerations itself. 362 6. IANA Considerations 364 This memo makes no requests of IANA. 366 7. Acknowledgements 368 The authors thank Adam Barth, Dave Crocker, Casey Deccio, Brian 369 Dickson, Jothan Frakes, Daniel Kahn Gillmor, Phillip Hallam-Baker, 370 John Klensin, Murray Kucherawy, Gervase Markham, Patrick McManus, 371 Henrik Nordstrom, Yngve N. Pettersen, Eric Rescorla, Thomas 372 Roessler, Peter Saint-Andre, Maciej Stachowiak, and Jeffrey Walton 373 for helpful comments or suggestions. 375 8. Informative References 377 [I-D.kucherawy-dmarc-base] 378 Kucherawy, M., "Domain-based Message Authentication, 379 Reporting and Conformance (DMARC)", draft-kucherawy-dmarc- 380 base-00 (work in progress), March 2013. 382 [I-D.pettersen-subtld-structure] 383 Pettersen, Y., "The Public Suffix Structure file format 384 and its use for Cookie domain validation", draft- 385 pettersen-subtld-structure-09 (work in progress), March 386 2012. 388 [publicsuffix.org] 389 Mozilla Foundation, "Public Suffix List", also known 390 as: Effective TLD (eTLD) List. 392 https://publicsuffix.org/ 394 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 395 STD 13, RFC 1034, November 1987. 397 [RFC1035] Mockapetris, P., "Domain names - implementation and 398 specification", STD 13, RFC 1035, November 1987. 400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 401 Requirement Levels", BCP 14, RFC 2119, March 1997. 403 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 404 Rose, "DNS Security Introduction and Requirements", 405 RFC 4033, March 2005. 407 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 408 Rose, "Resource Records for the DNS Security Extensions", 409 RFC 4034, March 2005. 411 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 412 Rose, "Protocol Modifications for the DNS Security 413 Extensions", RFC 4035, March 2005. 415 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 416 Security (DNSSEC) Hashed Authenticated Denial of 417 Existence", RFC 5155, March 2008. 419 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 420 Verification of Domain-Based Application Service Identity 421 within Internet Public Key Infrastructure Using X.509 422 (PKIX) Certificates in the Context of Transport Layer 423 Security (TLS)", RFC 6125, March 2011. 425 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 426 April 2011. 428 Appendix A. Discussion Venue 430 This Internet-Draft is discussed on the applications area working 431 group mailing list: dbound@ietf.org. 433 Appendix B. Change History 435 [this section to be removed by RFC-Editor prior to publication as an 436 RFC] 438 Version 01 Add questions from John Levine posting to mailing list. 440 Version 00 Initial version. 442 This is a -00 Internet-draft, but borrows from various prior draft 443 works, listed below, as well as from discussions on the mailing 444 list. 446 Andrew Sullivan, Jeff Hodges: Asserting DNS Administrative 447 Boundaries Within DNS Zones 449 http://tools.ietf.org/html/draft-sullivan-domain-policy- 450 authority-01 452 https://github.com/equalsJeffH/dbound/blob/master/draft- 453 sullivan-dbound-problem-statement-00.xml 455 John Levine: Publishing Organization Boundaries in the DNS 457 https://tools.ietf.org/html/draft-levine-orgboundary-02 459 https://github.com/equalsJeffH/dbound/blob/master/draft- 460 levine-orgboundary-02.txt 462 Casey Deccio, John Levine: Defining and Signaling 463 Relationships Between Domains 465 http://www.ietf.org/mail-archive/web/dbound/current/ 466 pdfwad2AxxkYo.pdf 468 http://www.ietf.org/mail-archive/web/dbound/current/ 469 msg00141.html 470 https://github.com/equalsJeffH/dbound/blob/master/deccio- 471 dbound-problem_statement-v3.pdf?raw=true 473 https://github.com/equalsJeffH/dbound/blob/master/deccio- 474 dbound-problem_statement-v3.txt 476 Authors' Addresses 478 Andrew Sullivan 479 Dyn, Inc. 480 150 Dow St 481 Manchester, NH 03101 482 U.S.A. 484 Email: asullivan@dyn.com 486 Jeff Hodges 487 PayPal 488 2211 North First Street 489 San Jose, California 95131 490 US 492 Email: Jeff.Hodges@KingsMountain.com 494 John Levine 495 Taughannock Networks 496 PO Box 727 497 Trumansburg, NY 14886 499 Phone: +1 831 480 2300 500 Email: standards@taugh.com 501 URI: http://jl.ly