idnits 2.17.1 draft-levine-dbound-dns-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 267: '...y policy records MUST have records for...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 6, 2019) is 1847 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 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 April 6, 2019 5 Expires: October 8, 2019 7 Publishing Organization Boundaries in the DNS 8 draft-levine-dbound-dns-02 10 Abstract 12 The organization that manages a subtree in the DNS is often different 13 from the one that manages the tree above it. We describe an 14 architecture to publish in the DNS the boundaries between 15 organizations that can be adapted to various policy models and can be 16 queried with a small number of DNS lookups. 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 https://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 October 8, 2019. 35 Copyright Notice 37 Copyright (c) 2019 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 (https://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. TXT record format . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Lookup Process . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. DNS Records . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 6. Application scenarios . . . . . . . . . . . . . . . . . . . . 6 58 6.1. DMARC . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6.2. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 6.3. SSL Certificates . . . . . . . . . . . . . . . . . . . . 7 61 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 8. ABNF syntax of bound records . . . . . . . . . . . . . . . . 7 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 10. Variations . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 66 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 12.2. Informative References . . . . . . . . . . . . . . . . . 10 69 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 Often, the organization that manages a subtree in the DNS is 75 different from the one that manages the tree above it. Many 76 applications use information about such boundaries to implement 77 security policies. For example, web browsers use them to limit the 78 names where web cookies can be set, and Secure Socket Layer (SSL) 79 certificate services use them to determine the party responsible for 80 the domain in a signing request. Mail security applications such as 81 Domain-based Messaging Authentication, Reporting and Conformance 82 (DMARC) use them to locate an organization's policy records in the 83 DNS. This specification is intended to provide boundaries usable for 84 DMARC, and possibly for other applications. 86 [[Please direct discussion of this draft to the dbound working group 87 at dbound@ietf.org.]] 89 2. Design Issues 91 Organization boundaries can be assigned on what one could call an 92 opt-in or opt-out basis. "Opt-in" means that two names are only 93 managed by the same organization if both actively assert that they 94 are related. "Opt-out" means that if there is any boundary 95 information at all for a DNS subtree, each name is assumed to be 96 under the same management as its parent unless there is a boundary 97 assertion to the contrary. This design describes an opt-out model. 99 Within the opt-out model, this design can adapt to a variety of 100 scenarios: 102 o Policies can be published by the domains themselves, or by a third 103 party. In the former case, each domain might assert its own 104 boundary policies. In the latter case, the third party makes the 105 assertions, which may or may not agree with what the domains 106 themselves would want. 108 o Multiple levels of delegation may be implemented, which is 109 different from irregular boundaries. For example, "ca", "on.ca", 110 and "toronto.on.ca" are irregular boundaries, because they're all 111 handled by the Canadian Internet Registration Authority (CIRA). 112 CentralNIC's "uk.com" would be a second level of delegation below 113 Verisign's com. 115 o Different sets of boundary rules can be published for different 116 applications. For example, the boundaries for SSL certificates 117 might be different from the boundaries for e-mail policies, or for 118 web cookie setting policies. 120 In the lookup process below, the boundary point data is stored in the 121 DNS tree in a TXT record. The boundary is considered to be directly 122 below the name that the process returns, similarly to the names in 123 the PSL [PSL]. If the process returned "abc.example", then 124 "foo.abc.example" and "bar.abc.example" are separated by the 125 boundary, but "foo.abc.example" and "bar.foo.abc.example" are not. 127 Each domain can publish its own policies within its own domain name 128 space, or a separate authority can publish a global set of policies 129 in a separate name space. 131 3. TXT record format 133 *.toronto.on._bound.ca IN TXT "bound=1 . . toronto.on.ca" 135 The "bound=1" tag is to prevent confusion when a domain publishes a 136 wildcard such as *.example.com that could match a _bound name. 138 The bound record contains a tag, two keyword strings and a domain 139 name. 141 Each keyword string is a series of comma separated keywords. If the 142 string would otherwise be empty, it is a single dot. 144 The first keyword string expresses policy options. It can include 145 NOLOWER which means that no lower level boundaries can exist below 146 this one, and NOBOUND which means that this name is not a boundary 147 for this application. 149 The second keyword string identifies the application(s) to which this 150 boundary applies. The strings DMARC, COOKIE, and CERT mean that the 151 applications re DMARC, HTTP cookies, and SSL certificate signing 152 respectively; a dot means it is a default for any applications not 153 otherwise specified. 155 4. Lookup Process 157 In general, the lookup process takes as input a domain name and 158 application. It returns the name of the boundary node in the DNS. 159 This may be the domain itself or a parent. If there is no policy for 160 the domain the lookup fails; there are no defaults, and the DNS root 161 is not within any organization boundary. (Applications may apply 162 defaults of their own, but that is beyond the scope of this 163 specification.) 165 Names of boundary information records use the tag "_bound" which is 166 intended to be unique. 168 For the first lookup, the client extracts the top level component 169 (i.e., the rightmost label, as "label" is defined in Section 3 of 170 [RFC1034]) of the domain name from the subcomponents, if any, and 171 inserts the prefix in front of that component, after other components 172 if any. For example, if the domain to be checked is "example.com" or 173 "www.example.com", the client issues a DNS query for 174 "example._bound.com" or "www.example._bound.com". If the domain is a 175 dotless one such as "example", the client looks up "_bound.example". 177 The client does a DNS lookup of TXT records at that name, which will 178 return zero or more TXT records. A failure such as NXDOMAIN is 179 considered to return zero records. A lookup can return multiple 180 records if different applications have different boundaries or policy 181 options. The lookup process discards any records that do not start 182 with "bound=1". 184 If a relevant policy record is returned, and the record does not 185 contain the NOBOUND keyword, the domain name in the record is the 186 policy boundary. A policy record is relevant if it lists the desired 187 application, or it is a default policy and there is no record with 188 the application's keyword. For example, a check for a boundary above 189 "example.com" would be issued at "example._bound.com", and the 190 expected TXT record could be "bound=1 . . com". 192 If there are no boundaries below the queried point, the policy record 193 contains "bound=1 NOBOUND . ." indicating the root. For example, if 194 all subdomains of the "example" top-level domain (TLD) are under the 195 same management as the TLD itself, checks for "_bound.example" or 196 "www._bound.example" would return "bound=1 NOBOUND . .". 198 If the relevant record has the NOLOWER keyword set, the process 199 stops. Otherwise, the client inserts the prefix tag into the name 200 just below (i.e., to the left of) the name at the largest matching 201 boundary indicated in the lookup result, and repeats the lookup. For 202 example: 204 o When evaluating "www.foo.example.com", the first query would be to 205 "www.foo.example._bound.com". If the reply to this is "bound=1 . 206 . com", then the second query would go to 207 "www.foo._bound.example.com". 209 o When evaluating "www.example.on.ca", the first query would be to 210 "www.example.on._bound.ca". If the reply to this is "bound=1 . . 211 on.ca", the next lookup would be to "www._bound.example.on.ca". 213 This process repeats until a DNS lookup returns a relevant record 214 with the NOLOWER keyword, or a lookup returns no relevant records, at 215 which point the boundary is the domain name in the last retrieved 216 relevant record. 218 If an otherwise relevant record has the NOBOUND keyword, the process 219 continues if the NOLOWER keyword is not present, but there is no 220 boundary at the name with the NOBOUND keyword. These NOBOUND keyword 221 enables a name in the hierarchy to be a boundary for some 222 applications but not for others. 224 5. DNS Records 226 The publishing entity uses wildcards and prefixed names that parallel 227 the regular names under a TLD to cover the domain's name space. 229 If there is a boundary at a given name, an entry in the TLD record 230 covers the names below it. For example, if there is a boundary at 231 ".TEST", a suitable record would be: 233 *._bound.test IN TXT "bound= . . test" 235 If the boundary is above the TEST domain, i.e., TEST is under the 236 same management as FOO.TEST, the record would indicate no boundaries, 237 and an additional non-wildcard record is needed to cover TEST itself: 239 *._bound.test IN TXT "bound=1 . . ." 240 _bound.test IN TXT "bound=1 . . ." 242 In domains with irregular policy boundaries, multiple records in the 243 record describe the boundary points. For example, in the CA (Canada) 244 TLD, for national organizations there might be a boundary directly 245 below the national TLD; for provincial organizations there might be a 246 boundary below a provincial subdomain such as "on.ca"; and for local 247 (e.g., municipal) organizations, a boundary below a municipal 248 subdomain such as "toronto.on.ca" might exist. A suitable set of of 249 records covers this structure. The closest encloser rule in RFC 4592 250 [RFC4592] makes the wildcards match the appropriate names. 252 *._bound.ca IN TXT "bound=1 . . ca" 253 *.on._bound.ca IN TXT "bound=1 . . on.ca" 254 *.toronto.on._bound.ca IN TXT "bound=1 . . toronto.on.ca" 256 For any set of policy boundaries in a tree of DNS names, a suitable 257 set of policy records can describe the boundaries, so a client can 258 find the boundary for any name in the tree with a single policy 259 lookup per level of delegation. 261 Since the delegation structure is unlikely to change frequently, long 262 time-to-live (TTL) values in the TXT records are appropriate. 264 If different applications have different boundaries or policy 265 options, the policy records for each application are put at the 266 appropriate names for the boundaries. Due to the way DNS wildcards 267 work, each name with any policy records MUST have records for all 268 policies, with the NOBOUND bit for policies for which the name is not 269 in fact a boundary. 271 6. Application scenarios 273 Here are some ways that DMARC and potentially other applications can 274 use BOUND data. 276 6.1. DMARC 278 If a DMARC lookup for the domain in a message's From: header fails, 279 the client would do a boundary check for the domain name using the 280 "DMARC" application. The organizational domain is the immediate 281 subdomain of the boundary domain. (Note that the boundary will 282 always be the one looked up or an ancestor.) 284 6.2. Cookies 286 If an http request attempts to set a cookie for a domain other than 287 the request's own domain, the client would do boundary check for a 288 "cookie" application for both the request's domain and the cookie 289 domain. If they are not separated by a boundary, the request is 290 allowed. 292 6.3. SSL Certificates 294 The client would do a boundary check for the domain name in an normal 295 certificate, or the name after the "*." in a wildcard certificate for 296 a "cert" application. If the boundary is above the name, the name is 297 allowed. 299 7. Discussion 301 The total number of DNS lookups is the number of levels of boundary 302 delegation, plus one if the last boundary doesn't have the NOLOWER 303 keyword. That is unlikely to be more than 2 or 3 in realistic 304 scenarios, and depends on the number of boundaries, not the number of 305 components in the names that are looked up. 307 Some domains have very irregular boundaries. This may require a 308 relatively large number of records to describe all the boundaries, 309 perhaps several hundred, but it doesn't seem like a number that would 310 challenge modern DNS servers, or need unduly complex scripts to 311 create them. 313 The wildcard lookup means that each time an application looks up the 314 boundaries for a hostname, the lookup results use DNS cache entries 315 that will not be reused other than for subsequent lookups for the 316 identical hostname. This might cause cache churn, but it seems at 317 worst no more than we already tolerate from DNSBL lookups. 319 8. ABNF syntax of bound records 321 The syntax of bound records is something like this: 323 BOUND = "bound=1" WSP BFLAGS WSP BKWDS WSP DOMAIN 325 BFLAGS = ( BFLAG *("," BFLAG) ) / "." 327 BFLAG = "NOLOWER" / "NOBOUND" 329 BKWDS = ( BKWD *("," BKWD) ) / "." 331 BKWD = "DMARC" / "COOKIE" / "CERT" 333 9. Security Considerations 335 The purpose of publishing organization boundaries is to provide 336 advice to third parties that wish to know whether two names are 337 managed by the same organization, allowing those names to be treated 338 "as the same" in some sense. Clients that rely on published 339 boundaries are outsourcing some part of their own security policy to 340 the publisher, so their own security depends on the publisher's 341 boundaries being accurate. 343 Although in some sense domains are always in control of their 344 subdomains, there are many situations in which parent domains are not 345 expected to influence subdomains. For example, second level domains 346 in global TLDs (gTLDs) operated by registries with contracts with the 347 Internet Corporation for Assigned Names and Numers (ICANN) Since 348 there is no technical bar to a parent publishing records that shadow 349 part or all of the boundary record namespace for delegated 350 subdomains, correct operation depends on the parent and subdomains 351 agreeing about who publishes what. 353 The DNS is subject to a variety of attacks. DBOUND records are 354 subject to the same ones as any other bit of the DNS, and the same 355 countermeasures, such as using DNSSEC, apply. 357 10. Variations 359 Some boundary schemes distinguish between public and private 360 subtrees. If that were useful, a PUBLIC flag keyword could indicate 361 that the subtrees below a boundary were public rather than the 362 default of private. 364 Since nothing but the boundary records should be published at names 365 with _bound components, one could get the same effect with a new 366 DBOUND RRTYPE, which would avoid the problem of confusion with other 367 TXT wildcards. 369 If third parties want to publish boundary information, they could do 370 it in their own subtree of the DNS. For example, if policy.example 371 were publishing boundary information about boundaries, the records 372 for the test domain described above would be: 374 *._bound.test.policy.exaple IN TXT "bound=1 . . ." 375 _bound.test.policy.example IN TXT "bound=1 . . ." 377 11. IANA considerations 379 This document defines a new _bound prefix keyword. 381 This document requests that IANA create a registry of dbound Flag 382 keywords. Its registration policy is IETF Review. Its initial 383 contents are as follows. [[NOTE: new flags are likely to change the 384 lookup algorithm]] 386 +---------+-----------------+--------------------------+ 387 | Keyword | Reference | Description | 388 +---------+-----------------+--------------------------+ 389 | NOLOWER | (this document) | No lower level policies | 390 | NOBOUND | (this document) | No boundary at this name | 391 +---------+-----------------+--------------------------+ 393 Table 1: BOUND Flag Keywords Initial Values 395 This document requests that IANA create a registry of BOUND 396 Application keywords. Its registration policy is First Come First 397 Served. Its initial contents are as follows. [[Note: New 398 applications don't affect the lookup process, and shouldn't affect 399 existing applications.]] 401 +--------+---------------+------------------------------------------+ 402 | Value | Reference | Description | 403 +--------+---------------+------------------------------------------+ 404 | . | (this | Any application without a specific | 405 | (Any) | document) | boundary record | 406 | DMARC | (this | DMARC organizational domains | 407 | | document) | | 408 | COOKIE | (this | HTTP cookies | 409 | | document) | | 410 | CERT | (this | Owner of certificate requests | 411 | | document) | | 412 +--------+---------------+------------------------------------------+ 414 Table 2: BOUND Applications Initial Values 416 12. References 418 12.1. Normative References 420 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 421 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 422 . 424 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 425 System", RFC 4592, DOI 10.17487/RFC4592, July 2006, 426 . 428 12.2. Informative References 430 [PSL] Mozilla Foundation, "Public Suffix List", Nov 2015. 432 Appendix A. Change Log 434 *NOTE TO RFC EDITOR: This section may be removed upon publication of 435 this document as an RFC.* 437 01 to -02 Make TXT record the proposal, new RR as alternative. 439 -00 to -01 Editorial changes to limit standard use to DMARC. 441 non-WG to -00 Add NOBOUND record to make wildcard matches do the 442 right thing 444 Rename to match WG name 446 Author's Address 448 John Levine 449 Taughannock Networks 450 PO Box 727 451 Trumansburg, NY 14886 453 Phone: +1 646 481 7726 454 Email: standards@taugh.com 455 URI: http://jl.ly