idnits 2.17.1 draft-levine-orgboundary-04.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 2 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 (November 18, 2015) is 3075 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Levine 3 Internet-Draft Taughannock Networks 4 Intended status: Informational November 18, 2015 5 Expires: May 21, 2016 7 Publishing Organization Boundaries in the DNS 8 draft-levine-orgboundary-04 10 Abstract 12 Often, the organization that manages a subtree in the DNS is 13 different from the one that manages the tree above it. Rather than 14 describing a particular design, we describe an architecture to 15 publish in the DNS the boundaries between organizations that can be 16 adapted to various policy models. 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 May 21, 2016. 35 Copyright Notice 37 Copyright (c) 2015 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 2. Design Issues . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. RRTYPE format . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Lookup Process . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. DNS Records . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 6. Application scenearios . . . . . . . . . . . . . . . . . . . 6 58 6.1. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6.2. SSL Certificates . . . . . . . . . . . . . . . . . . . . 6 60 6.3. DMARC . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 9. Variations . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 11.2. Informative References . . . . . . . . . . . . . . . . . 9 68 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 69 A.1. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 9 70 A.2. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 9 71 A.3. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 9 72 A.4. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 9 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 Often, the organization that manages a subtree in the DNS is 78 different from the one that manages the tree above it. Many 79 applications use information about such boundaries to implement 80 security policies. For example, web browsers use them to limit the 81 names where web cookies can be set, and Secure Socket Layer (SSL) 82 certificate services use them to determine the party responsible for 83 the domain in a signing request. Some mail security applications 84 such as Domain-based Messaging Authentication, Reporting and 85 Conformance (DMARC) use them to locate an organization's policy 86 records in the DNS. 88 [[Please direct discussion of this draft to the dbound working group 89 at dbound@ietf.org.]] 91 2. Design Issues 93 Organization boundaries can be assigned on what one could call an 94 opt-in or opt-out basis. "Opt-in" means that two names are only 95 managed by the same organization if both actively assert that they 96 are related. "Opt-out" means that if there is any boundary 97 information at all for a DNS subtree, each name is assumed to be 98 under the same management as its parent unless there is a boundary 99 assertion to the contrary. This design describes an opt-out model. 101 Within the opt-out model, this design can adapt to a variety of 102 scenarios: 104 o Policies can be published by the domains themselves, or by a third 105 party. In the former case, each domain might assert its own 106 boundary policies. In the latter case, the third party makes the 107 assertions, which may or may not agree with what the domains 108 themselves would want. 110 o Multiple levels of delegation may be implemented, which is 111 different from irregular boundaries. For example, "ca", "on.ca", 112 and "toronto.on.ca" are irregular boundaries, because they're all 113 handled by the Canadian Internet Registration Authority (CIRA). 114 CentralNIC's "uk.com" would be a second level of delegation below 115 Verisign's com. 117 o Different sets of boundary rules can be published for different 118 applications. For example, the boundaries for SSL certificates 119 might be different from the boundaries for e-mail policies, or for 120 web cookie setting policies. 122 In the lookup process below, the boundary point data is stored in the 123 DNS tree in a new BOUND RRTYPE. The boundary is considered to be 124 directly below the name that the process returns, similarly to the 125 names in the PSL [PSL]. If the process returned "abc.example", then 126 "foo.abc.example" and "bar.abc.example" are separated by the 127 boundary, but "foo.abc.example" and "foo.bar.abc.example" are not. 129 Each domain publishes its own policies. 131 3. RRTYPE format 133 The BOUND record contains two 16-bit numeric values and an 134 uncompressed domain name. In a master file, they are written as two 135 decimal values and a domain name. 137 The first numeric value is a bit mask expressing policy options. The 138 only bit currently assigned is 0x0001 (NOLOWER) which means that no 139 lower level boundaries can exist below this one. 141 The second numeric value is a number identifying the application to 142 which this boundary applies. The number zero is a default for any 143 applications not otherwise specified. 145 4. Lookup Process 147 In general, the lookup process takes as input a domain name an 148 application number. It returns the name of the boundary node in the 149 DNS. This may be the domain itself or a parent. If there is no 150 policy for the domain the lookup fails; there are no defaults, and 151 the DNS root is not within any organization boundary. (Applications 152 may apply defaults of their own, but that is beyond the scope of this 153 specification.) 155 Names of boundary information records use the tag "_bound" which is 156 intended to be unique. 158 For the first lookup, the client extracts the top level component 159 (i.e., the rightmost label, as "label" is defined in Section 3 of 160 [RFC1034]) of the domain name from the subcomponents, if any, and 161 inserts the prefix in front of that component, after other components 162 if any. For example, if the domain to be checked is "example.com" or 163 "www.example.com", the client issues a DNS query for 164 "example._bound.com" or "www.example._bound.com". If the domain is a 165 dotless one such as "example", the client looks up "_bound.example". 167 The client does a DNS lookup of BOUND records at that name, which 168 will return zero or more BOUND records. A failure such as NXDOMAIN 169 is considered to return zero records. A lookup can return multiple 170 records if different applications have different boundaries or policy 171 options. 173 If a relevant policy record is returned, the domain name in the 174 record is the policy boundary. A policy record is relevant if it its 175 application number is the application's number, or its application 176 number is zero and there is no record with the application's number. 177 For example, a check for a boundary above "example.com" would be 178 issued at "example._bound.com", and the expected response could be 179 "BOUND 0 0 com". 181 If there are no boundaries below the queried point, the policy record 182 contains "BOUND 1 0 ." indicating the root. For example, if all 183 subdomains of the "example" top-level domain (TLD) are under the same 184 management as the TLD itself, checks for "_bound.example" or 185 "www._bound.example" would return "BOUND 1 0 .". 187 If the relevant record has the NOLOWER bit set, the process stops. 188 Otherwise, the client inserts the prefix tag into the name just below 189 (i.e., to the left of) the name at the largest matching boundary 190 indicated in the lookup result, and repeats the lookup. For example: 192 o When evaluating "www.foo.example.com", the first query would be to 193 "www.foo.example._bound.com". If the reply to this is "BOUND 0 0 194 com", then the second query would go to 195 "www.foo._bound.example.com". 197 o When evaluating "www.example.on.ca", the first query would be to 198 "www.example.on._bound.ca". If the reply to this is "BOUND 0 0 199 on.ca", the next lookup would be to "www._bound.example.on.ca". 201 This process repeats until a DNS lookup returns a relevant record 202 with the NOLOWER bit set, or a lookup returns no relevant records, at 203 which point the boundary is the domain name in the last retrieved 204 relevant record. 206 5. DNS Records 208 The publishing entity uses wildcards and prefixed names that parallel 209 the regular names under a TLD to cover the domain's name space. 211 If there is a boundary at a given name, an entry in the TLD record 212 covers the names below it. For example, if there is a boundary at 213 ".TEST", a suitable record would be: 215 *._bound.test IN BOUND 0 0 test" 217 If the boundary is above the TEST domain, i.e., TEST is under the 218 same management as FOO.TEST, the record would indicate no boundaries, 219 and an additional non-wildcard record is needed to cover TEST itself: 221 *._bound.test IN BOUND 0 0 . 222 _bound.test IN BOUND 0 0 . 224 In domains with irregular policy boundaries, multiple records in the 225 record describe the boundary points. For example, in the CA (Canada) 226 TLD, for national organizations there might be a boundary directly 227 below the national TLD; for provincial organizations there might be a 228 boundary below a provincial subdomain such as "on.ca"; and for local 229 (e.g., municipal) organizations, a boundary below a municipal 230 subdomain such as "toronto.on.ca" might exist. A suitable set of of 231 records covers this structure. The closest encloser rule in RFC 4592 232 [RFC4592] makes the wildcards match the appropriate names. 234 *._bound.ca IN BOUND 0 0 ca 235 *.on._bound.ca IN BOUND 0 0 on.ca 236 *.toronto.on._bound.ca IN BOUND 0 0 toronto.on.ca" 238 For any set of policy boundaries in a tree of DNS names, a suitable 239 set of policy records can describe the boundaries, so a client can 240 find the boundary for any name in the tree with a single policy 241 lookup per level of delegation. 243 Since the delegation structure is unlikely to change frequently, long 244 time-to-live (TTL) values in the DBOUND records are appropriate. 246 If different applications have different boundaries or policy 247 options, the policy records for each application are put at the 248 appropriate names for the boundaries. 250 6. Application scenearios 252 Here are some ways that applications might use BOUND data. 254 6.1. Cookies 256 If an http request attempts to set a cookie for a domain other than 257 the request's own domain, the client would do boundary check for the 258 "cookie" application for both the request's domain and the cookie 259 domain. If they are not separated by a boundary, the request is 260 allowed. 262 6.2. SSL Certificates 264 The client would do a boundary check for the domain name in an normal 265 certificate, or the name after the "*." in a wildcard certificate for 266 the "cert" application. If the boundary is above the name, the name 267 is allowed. 269 6.3. DMARC 271 If a DMARC lookup for the domain in a message's From: header fails, 272 the client would do a boundary check for the domain name using the 273 "dmarc" application. The organizational domain is the immediate 274 subdomain of the boundary domain. (Note that the boundary will 275 always be the one looked up or an ancestor.) 277 7. Discussion 279 The total number of DNS lookups is the number of levels of boundary 280 delegation, plus one if the last boundary doesn't have the NOLOWER 281 flag. That is unlikely to be more than 2 or 3 in realistic 282 scenarios, and depends on the number of boundaries, not the number of 283 components in the names that are looked up. 285 Some domains have very irregular boundaries. This may require a 286 large number of records to describe all the boundaries, perhaps 287 several hundred, but it doesn't seem like a number that would 288 challenge modern DNS servers. 290 The wildcard lookup means that each time an application looks up the 291 boundaries for a hostname, the lookup results use DNS cache entries 292 that will not be reused other than for subsequent lookups for the 293 identical hostname. This might cause cache churn, but it seems at 294 worst no more than we already tolerate from DNSBL lookups. 296 8. Security Considerations 298 The purpose of publishing organization boundaries is to provide 299 advice to third parties that wish to know whether two names are 300 managed by the same organization, allowing those names to be treated 301 "as the same" in some sense. Clients that rely on published 302 boundaries are outsourcing some part of their own security policy to 303 the publisher, so their own security depends on the publisher's 304 boundaries being accurate. 306 Although in some sense domains are always in control of their 307 subdomains, there are many situations in which parent domains are not 308 expected to influence subdomains. For example, the Internet 309 Corporation for Assigned Names and Numers (ICANN) contracted global 310 TLDs (gTLDs) and registers second level domains. Since there is no 311 technical bar to a parent publishing records that shadow part or all 312 of the boundary record namespace for delegated subdomains, correct 313 operation depends on the parent and subdomains agreeing about who 314 publishes what. 316 The DNS is subject to a variety of attacks. DBOUND records are 317 subject to the same ones as any other bit of the DNS, and the same 318 responses, such as using DNSSEC, apply. 320 9. Variations 322 Since nothing but BOUND records should be published at names with 323 _bound components, one could get the same effect with TXT records, 324 e.g.: 326 *.toronto.on._ob.ca IN TXT "bound=1 0 0 toronto.on.ca" 328 The "bound=1" tag is to prevent confusion when a domain publishes a 329 wildcard such as *.example.com that could match a _bound name. 331 If third parties wanted to publish boundary information, they could 332 do it in their own subtree of the DNS. For example, if 333 polgroup.example were publishing boundary information about 334 boundaries, the records for the test domain described above would be: 336 *._bound.test.polgroup.exaple IN BOUND 0 0 . 337 _bound.test.polgroup.example IN BOUND 0 0 . 339 10. IANA considerations 341 This document defines a new DBOUND RRTYPE. IANA has assigned value 342 TBD. 344 This document requests that IANA create a registry of BOUND Flag 345 Bits. Its registration policy is IETF Review. Its initial contents 346 are as follows. [[NOTE: new flags are likely to change the lookup 347 algorithm]] 349 +------------------+-----------------+-------------------------+ 350 | Bit | Reference | Description | 351 +------------------+-----------------+-------------------------+ 352 | 0x0001 (NOLOWER) | (this document) | No lower level policies | 353 +------------------+-----------------+-------------------------+ 355 Table 1: BOUND Flag Bits Initial Values 357 This document requests that IANA create a registry of BOUND 358 Applications. Its registration policy is First Come First Served. 359 Its initial contents are as follows. [[Note: New applications don't 360 affect the lookup process, and shouldn't affect existing 361 applications.]] 363 +------------+-----------------+------------------------------+ 364 | Value | Reference | Description | 365 +------------+-----------------+------------------------------+ 366 | 0 (Any) | (this document) | Any application | 367 | 1 (Cookie) | (this document) | HTTP web cookies | 368 | 2 (Cert) | (this document) | SSL certificate authorities | 369 | 3 (DMARC) | (this document) | DMARC organizational domains | 370 +------------+-----------------+------------------------------+ 372 Table 2: BOUND Applications Initial Values 374 11. References 376 11.1. Normative References 378 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 379 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 380 . 382 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 383 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 384 . 386 11.2. Informative References 388 [PSL] Mozilla Foundation, "Public Suffix List", Nov 2015. 390 Appendix A. Change Log 392 *NOTE TO RFC EDITOR: This section may be removed upon publication of 393 this document as an RFC.* 395 A.1. Changes from -03 to -04 397 Editorial changes, fix speling errors. 399 A.2. Changes from -02 to -03 401 New BOUND record type and modified lookup procedure. 403 A.3. Changes from -01 to -02 405 Add ABNF. 407 MSK overhaul of the middle part. 409 Put the wildcards back. 411 A.4. Changes from -00 to -01 413 Take out wildcards and put everything in one record. 415 Add DNS nits. 417 Author's Address 419 John Levine 420 Taughannock Networks 421 PO Box 727 422 Trumansburg, NY 14886 424 Phone: +1 831 480 2300 425 Email: standards@taugh.com 426 URI: http://jl.ly