idnits 2.17.1 draft-ietf-dmarc-psd-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (May 7, 2019) is 1816 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Kitterman 3 Internet-Draft fTLD Registry Services 4 Intended status: Experimental May 7, 2019 5 Expires: November 8, 2019 7 DMARC (Domain-based Message Authentication, Reporting, and Conformance) 8 Extension For PSDs (Public Suffix Domains) 9 draft-ietf-dmarc-psd-03 11 Abstract 13 DMARC (Domain-based Message Authentication, Reporting, and 14 Conformance) is a scalable mechanism by which a mail-originating 15 organization can express domain-level policies and preferences for 16 message validation, disposition, and reporting, that a mail-receiving 17 organization can use to improve mail handling. DMARC policies can be 18 applied at the individual domain level or for a set of domains at the 19 organizational level. The design of DMARC precludes grouping 20 policies for a set of domains above the organizational level, such as 21 TLDs (Top Level Domains). These types of domains (which are not all 22 at the top level of the DNS tree) can be collectively referred to as 23 Public Suffix Domains (PSDs). For the subset of PSDs that require 24 DMARC usage, this memo describes an extension to DMARC to enable 25 DMARC functionality for such domains. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 8, 2019. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 63 2.1. Conventions Used in This Document . . . . . . . . . . . . 4 64 2.2. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 4 65 2.3. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.4. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 5 67 2.5. PSO Controlled Domain Names . . . . . . . . . . . . . . . 5 68 2.6. Non-existent Domains . . . . . . . . . . . . . . . . . . 5 69 3. PSD DMARC Updates to DMARC Requirements . . . . . . . . . . . 5 70 3.1. General Updates . . . . . . . . . . . . . . . . . . . . . 5 71 3.2. Section 6.1 DMARC Policy Record . . . . . . . . . . . . . 5 72 3.3. Section 6.5. Domain Owner Actions . . . . . . . . . . . 5 73 3.4. Section 6.6.3. Policy Discovery . . . . . . . . . . . . 6 74 3.5. Section 7. DMARC Feedback . . . . . . . . . . . . . . . 6 75 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 76 4.1. Feedback leakage . . . . . . . . . . . . . . . . . . . . 6 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 81 7.2. Informative References . . . . . . . . . . . . . . . . . 8 82 Appendix A. The Experiment . . . . . . . . . . . . . . . . . . . 9 83 Appendix B. DMARC PSD Registry Examples . . . . . . . . . . . . 10 84 B.1. DMARC PSD DNS Query Service . . . . . . . . . . . . . . . 10 85 B.2. DMARC Public Suffix Domain (PSD) Registry . . . . . . . . 10 86 Appendix C. Implementation . . . . . . . . . . . . . . . . . . . 11 87 C.1. Authheaders Module . . . . . . . . . . . . . . . . . . . 11 88 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 91 1. Introduction 93 DMARC [RFC7489] provides a mechanism for publishing organizational 94 policy information to email receivers. DMARC [RFC7489] allows policy 95 to be specified for both individual domains and sets of domains 96 within a single organization. For domains above the organizational 97 level in the DNS tree, policy can only be published for the exact 98 domain. There is no method available to such domains to express 99 lower level policy or receive feedback reporting for sets of domains. 100 This prevents policy application to non-existent domains and 101 identification of domain abuse in email, which can be important for 102 brand and consumer protection. 104 As an example, imagine a country code TLD (ccTLD) which has public 105 subdomains for government and commercial use (.gov.example and 106 .com.example). Within the .gov.example public suffix, use of DMARC 107 [RFC7489] has been mandated and .gov.example has published its own 108 DMARC [RFC7489] record: 110 "v=DMARC1;p=reject;rua=mailto:dmarc@dmarc.service.gov.example" 112 at 114 _dmarc.gov.example. 116 This would provide policy and feedback for mail sent from 117 @gov.example, but not @tax.gov.example and there is no way to publish 118 an organizational level policy that would do so. While, in theory, 119 receivers could reject mail from non-existent domains, not all 120 receivers do so. Non-existence of the sending domain can be a factor 121 in a mail delivery decision, but is not generally treated as 122 definitive on its own. 124 This memo provides a simple extension to DMARC [RFC7489] to allow 125 operators of Public Suffix Domains (PSDs) to express policy for 126 groups of subdomains, extends the DMARC [RFC7489] policy query 127 functionality to detect and process such a policy, describes receiver 128 feedback for such policies, and provides controls to mitigate 129 potential privacy considerations associated with this extension. 131 As an additional benefit, the PSD DMARC extension will clarify 132 existing requirements. Based on the requirements of DMARC [RFC7489], 133 DMARC should function above the organizational level for exact domain 134 matches (i.e. if a DMARC record were published for 'example', then 135 mail from example@example should be subject to DMARC processing. 136 Testing had revealed that this is not consistently applied in 137 different implementations. PSD DMARC will help clarify that DMARC is 138 not limited to organizational domains and their sub-domains. 140 There are two types of Public Suffix Operators (PSOs) for which this 141 extension would be useful and appropriate: 143 o Branded PSDs (e.g., ".google"): These domains are effectively 144 Organizational Domains as discussed in DMARC [RFC7489]. They 145 control all subdomains of the tree. These are effectively private 146 domains, but listed in the Public Suffix List. They are treated 147 as Public for DMARC [RFC7489] purposes. They require the same 148 protections as DMARC [RFC7489] Organizational Domains, but are 149 currently excluded. 151 o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): 152 Because existing Organizational Domains using this PSD have their 153 own DMARC policy, the applicability of this extension is for non- 154 existent domains. The extension allows the brand protection 155 benefits of DMARC [RFC7489] to extend to the entire PSD, including 156 cousin domains of registered organizations. 158 Due to the design of DMARC [RFC7489] and the nature of the Internet 159 email architecture [RFC5598], there are interoperability issues 160 associated with DMARC [RFC7489] deployment. These are discussed in 161 Interoperability Issues between DMARC and Indirect Email Flows 162 [RFC7960]. These issues are not applicable to PSDs, since they 163 (e.g., the ".gov.example" used above) do not send mail. 165 DMARC [RFC7489], by design, does not support usage by PSOs. For PSDs 166 that require use of DMARC [RFC7489], an extension of DMARC reporting 167 and enforcement capability is needed for PSO to effectively manage 168 and monitor implementation of PSD requirements. 170 2. Terminology and Definitions 172 This section defines terms used in the rest of the document. 174 2.1. Conventions Used in This Document 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 178 "OPTIONAL" in this document are to be interpreted as described in 179 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 180 capitals, as shown here. 182 2.2. Public Suffix Domain (PSD) 184 The global Internet Domain Name System (DNS) is documented in 185 numerous Requests for Comment (RFC). It defines a tree of names 186 starting with root, ".", immediately below which are Top Level Domain 187 names such as ".com" and ".us". They are not available for private 188 registration. In many cases the public portion of the DNS tree is 189 more than one level deep. PSD DMARC includes all public domains 190 above the organizational level in the tree, e.g., ".gov.uk". 192 2.3. Longest PSD 194 Organizational Domain (DMARC [RFC7489] Section 3.2) with one label 195 removed. 197 2.4. Public Suffix Operator (PSO) 199 A Public Suffix Operator manages operations within their PSD. 201 2.5. PSO Controlled Domain Names 203 PSO Controlled Domain Names are names in the DNS that are managed by 204 a PSO and are not available for use as Organizational Domains (the 205 term Organizational Domains is defined in DMARC [RFC7489] 206 Section 3.2). Depending on PSD policy, these will have one (e.g., 207 ".com") or more (e.g., ".co.uk") name components. 209 2.6. Non-existent Domains 211 For DMARC [RFC7489] purposes, a non-existent domain is a domain name 212 that publishes none of A, AAAA, or MX records that the receiver is 213 willing to accept. This is a broader definition than that in 214 NXDOMAIN [RFC8020]. 216 3. PSD DMARC Updates to DMARC Requirements 218 This document updates DMARC [RFC7489] as follows: 220 3.1. General Updates 222 References to "Domain Owners" also apply to PSOs. 224 3.2. Section 6.1 DMARC Policy Record 226 PSD DMARC records are published as a subdomain of the PSD. For the 227 PSD ".example", the PSO would post DMARC policy in a TXT record at 228 "_dmarc.example". 230 3.3. Section 6.5. Domain Owner Actions 232 In addition to the DMARC [RFC7489] domain owner actions, PSOs that 233 require use of DMARC ought to make that information available to 234 receivers. 236 3.4. Section 6.6.3. Policy Discovery 238 A new step between step 3 and 4 is added: 240 3A. If the set is now empty and the longest PSD (Section 2.3) of the 241 Organizational Domain is one that the receiver has determined is 242 acceptable for PSD DMARC, the Mail Receiver MUST query the DNS for 243 a DMARC TXT record at the DNS domain matching the longest PSD 244 (Section 2.3) in place of the RFC5322.From domain in the message 245 (if different). A possibly empty set of records is returned. 247 As an example, for a message with the Organizational Domain of 248 "example.compute.cloudcompany.com.cctld", the query for PSD DMARC 249 would use "compute.cloudcompany.com.cctld" as the longest PSD 250 (Section 2.3). The receiver would check to see if that PSD is listed 251 in the DMARC PSD Registry, and if so, perform the policy lookup at 252 "_dmarc.compute.cloudcompany.com.cctld". 254 Note: Because the PSD policy query comes after the Organizational 255 Domain policy query, PSD policy is not used for Organizational 256 domains that have published a DMARC [RFC7489] policy. Specifically, 257 this is not a mechanism to provide feedback addresses (RUA/RUF) when 258 an Organizational Domain has declined to do so. 260 3.5. Section 7. DMARC Feedback 262 [RFC7489] Section 7.3 Failure Reports MUST NOT be sent for PSD DMARC. 264 Operational note for PSD DMARC: For PSOs, feedback for non-existent 265 domains is desired and useful. See Section 4 for discussion of 266 Privacy Considerations. 268 4. Privacy Considerations 270 These privacy considerations are developed based on the requiremetns 271 of [RFC6973]. The Privacy Considerations of [RFC7489] apply to this 272 document. 274 4.1. Feedback leakage 276 Providing feedback reporting to PSOs can, in some cases, create 277 leakage of information outside of an organization to the PSO. This 278 leakage could be potentially be utilized as part of a program of 279 pervasive surveillance (See [RFC7624]). There are roughly three 280 cases to consider: 282 o Single Organization PSDs (e.g., ".google"), RUA and RUF reports 283 based on PSD DMARC have the potential to contain information about 284 emails related to entities managed by the organization. Since 285 both the PSO and the Organizational Domain owners are common, 286 there is no additional privacy risk for either normal or non- 287 existent Domain reporting due to PSD DMARC. 289 o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): 290 PSD DMARC based reports will only be generated for domains that do 291 not publish a DMARC policy at the organizational or host level. 292 For domains that do publish the required DMARC policy records, the 293 feedback reporting addresses (RUA and RUF) of the organization (or 294 hosts) will be used. The only direct feedback leakage risk for 295 these PSDs are for Organizational Domains that are out of 296 compliance with PSD policy. Data on non-existent cousin domains 297 would be sent to the PSO. 299 o Multi-organization PSDs (e.g., ".com") that do not mandate DMARC 300 usage: Privacy risks for Organizational Domains that have not 301 deployed DMARC within such PSDs are significant. For non-DMARC 302 Organizational Domains, all DMARC feedback will be directed to the 303 PSO. PSD DMARC is opt-out (by publishing a DMARC record at the 304 Organizational Domain level) vice opt-in, which would be the more 305 desirable characteristic. This means that any non-DMARC 306 organizational domain would have it's feedback reports redirected 307 to the PSO. The content of such reports, particularly for 308 existing domains, is privacy sensitive. 310 PSOs will receive feedback on non-existent domains, which may be 311 similar to existing Organizational Domains. Feedback related to such 312 cousin domains have a small risk of carrying information related to 313 an actual Organizational Domain. To minimize this potential concern, 314 PSD DMARC feedback is best limited to Aggregate Reports. Feedback 315 Reports carry more detailed information and present a greater risk. 317 Due to the inherent Privacy and Security risks associated with PSD 318 DMARC for Organizational Domains in multi-organization PSDs that do 319 not particpate in DMARC, any Feedback Reporting related to multi- 320 organizational PSDs ought to be limited to non-existent domains 321 except in cases where the reporter knows that PSO requires use of 322 DMARC. 324 5. Security Considerations 326 This document does not change the Security Considerations of 327 [RFC7489] and [RFC7960]. 329 The risks of the issues identified in [RFC7489], Section 12.5, 330 External Reporting Addresses, are amplified by PSD DMARC. By design, 331 PSD DMARC causes unrequested reporting of feedback to entities 332 external to the Organizational Domain. This is discussed in more 333 detail in Section 4. 335 6. IANA Considerations 337 This document does not require any IANA actions. 339 7. References 341 7.1. Normative References 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, 345 DOI 10.17487/RFC2119, March 1997, 346 . 348 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 349 Message Authentication, Reporting, and Conformance 350 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 351 . 353 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 354 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 355 May 2017, . 357 7.2. Informative References 359 [psddmarc.org] 360 multiple, "PSD DMARC Web Site", April 2019, 361 . 363 [PSL] multiple, "Public Suffix List", April 2019, 364 . 366 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 367 IANA Considerations Section in RFCs", RFC 5226, 368 DOI 10.17487/RFC5226, May 2008, 369 . 371 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 372 DOI 10.17487/RFC5598, July 2009, 373 . 375 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 376 Morris, J., Hansen, M., and R. Smith, "Privacy 377 Considerations for Internet Protocols", RFC 6973, 378 DOI 10.17487/RFC6973, July 2013, 379 . 381 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 382 Trammell, B., Huitema, C., and D. Borkmann, 383 "Confidentiality in the Face of Pervasive Surveillance: A 384 Threat Model and Problem Statement", RFC 7624, 385 DOI 10.17487/RFC7624, August 2015, 386 . 388 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, 389 E., Ed., and K. Andersen, Ed., "Interoperability Issues 390 between Domain-based Message Authentication, Reporting, 391 and Conformance (DMARC) and Indirect Email Flows", 392 RFC 7960, DOI 10.17487/RFC7960, September 2016, 393 . 395 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is 396 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, 397 November 2016, . 399 Appendix A. The Experiment 401 To mitigate the privacy concerns associated with Multi-organization 402 PSDs that do not mandate DMARC usage, see Section 4.1, a mechanism to 403 indicate which PSDs do not present this privacy risk is appropriate. 404 There are multiple approaches that are possible. 406 The experiment is to evaluate different possible approaches. The 407 experiment will be complete when there is rough consensus on a 408 technical approach that is demonstrated to be operationally usable 409 and effective at mitigating the privacy concern. 411 The mechanism needs the following attributes: 413 o Be reliably, publicly accessible 415 o Be under configuration control based on a public set of criteria 417 o List PSDs that either mandate DMARC for their registrants or for 418 which all lower level domains are controlled by the PSO and that 419 the relevant PSO has indicated a desire for the PSD to participate 420 in PSD DMARC 422 o Have a small operational footprint (e.g. provide a documented, 423 lightweight mechanism for developers and operators to retrieve the 424 list of PSD DMARC participants) 426 o Not allow PSO to add PSDs to the PSD DMARC participants list 427 without third party review 429 As of this writing, three approaches have been proposed. None of 430 them are ideal: 432 o An extension to the Public Suffix List at [PSL] 434 o A dedicated registry queried via DNS - an example of such a 435 service is described in Appendix B.1 below 437 o An IANA registry 439 Appendix B. DMARC PSD Registry Examples 441 To faciliate experimentation around data leakage mitigation, samples 442 of the DNS based and IANA like registries are available at 443 [psddmarc.org]. 445 B.1. DMARC PSD DNS Query Service 447 A sample stand-alone DNS query service is available at 448 [psddmarc.org]. It was developed based on the contents suggested for 449 an IANA registry in an earlier revision of this draft. Usage of the 450 service is described on the web site. 452 B.2. DMARC Public Suffix Domain (PSD) Registry 454 [psddmarc.org] provides an IANA like DMARC Public Suffix Domain (PSD) 455 Registry as a stand-alone DNS query service. It follows the contents 456 and structure described below. There is a Comma Separated Value 457 (CSV) version of the listed PSD domains which is suitable for use in 458 build updates for PSD DMARC capable software. 460 Names of PSDs participating in PSD DMARC must be registered this new 461 registry. New entries are assigned only for PSDs that require use of 462 DMARC. The requirement has to be documented in a manner that 463 satisfies the terms of Expert Review,per [RFC5226]. The Designated 464 Expert needs to confirm that provided documentation adequately 465 describes PSD policy to require domain owners to use DMARC or that 466 all domain owners are part of a single organization with the PSO. 468 The initial set of entries in this registry is as follows: 470 +-------------+---------------+ 471 | PSD | Status | 472 +-------------+---------------+ 473 | .bank | current | 474 +-------------+---------------+ 475 | .insurance | current | 476 +-------------+---------------+ 477 | .gov.uk | current | 478 +-------------+---------------+ 480 Appendix C. Implementation 482 There is one known implementation of PSD DMARC available for testing. 484 C.1. Authheaders Module 486 The authheaders Python module and command line tool is available for 487 download or installation from Pypi (Python Packaging Index). 489 It supports both use of the DNS based query service and download of 490 the CSV registry file from [psddmarc.org]. 492 Acknowledgements 494 Thanks to the following individuals for their contributions (both 495 public and private) to improving this document. Special shout out to 496 Dave Crocker for naming the beast. 498 Kurt Andersen, Seth Blank, Dave Crocker, Heather Diaz, Tim Draegen, 499 Zeke Hendrickson, Andrew Kennedy, John Levine, Dr Ian Levy, Craig 500 Schwartz, Alessandro Vesely, and Tim Wicinski 502 Author's Address 504 Scott Kitterman 505 fTLD Registry Services 506 600 13th Street, NW, Suite 400 507 Washington, DC 20005 508 United States of America 510 Phone: +1 301 325-5475 511 Email: scott@kitterman.com