idnits 2.17.1 draft-ietf-dmarc-psd-01.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7489, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 14, 2019) is 1923 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. 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 Updates: 7489 (if approved) January 14, 2019 5 Intended status: Informational 6 Expires: July 18, 2019 8 DMARC (Domain-based Message Authentication, Reporting, and Conformance) 9 Extension For PSDs (Public Suffix Domains) 10 draft-ietf-dmarc-psd-01 12 Abstract 14 DMARC (Domain-based Message Authentication, Reporting, and 15 Conformance) is a scalable mechanism by which a mail-originating 16 organization can express domain-level policies and preferences for 17 message validation, disposition, and reporting, that a mail-receiving 18 organization can use to improve mail handling. DMARC policies can be 19 applied at the individual domain level or for a set of domains at the 20 organizational level. The design of DMARC precludes grouping 21 policies for a set of domains above the organizational level, such as 22 TLDs (Top Level Domains). These types of domains (which are not all 23 at the top level of the DNS tree) can be collectively referred to as 24 Public Suffix Domains (PSDs). For the subset of PSDs that require 25 DMARC usage, this memo describes an extension to DMARC to enable 26 DMARC functionality for such domains. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 18, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 64 2.1. Conventions Used in This Document . . . . . . . . . . . . 4 65 2.2. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 4 66 2.3. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.4. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 4 68 2.5. PSO Controlled Domain Names . . . . . . . . . . . . . . . 5 69 2.6. Non-existent Domains . . . . . . . . . . . . . . . . . . 5 70 3. PSD DMARC Updates to DMARC Requirements . . . . . . . . . . . 5 71 3.1. General Updates . . . . . . . . . . . . . . . . . . . . . 5 72 3.2. Section 6.1 DMARC Policy Record . . . . . . . . . . . . . 5 73 3.3. Section 6.5. Domain Owner Actions . . . . . . . . . . . 5 74 3.4. Section 6.6.3. Policy Discovery . . . . . . . . . . . . 5 75 3.5. Section 7. DMARC Feedback . . . . . . . . . . . . . . . 6 76 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 77 4.1. Feedback leakage . . . . . . . . . . . . . . . . . . . . 6 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 82 7.2. Informative References . . . . . . . . . . . . . . . . . 8 83 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 86 1. Introduction 88 DMARC [RFC7489] provides a mechanism for publishing organizational 89 policy information to email receivers. DMARC [RFC7489] allows policy 90 to be specified for both individual domains and sets of domains 91 within a single organization. For domains above the organizational 92 level in the DNS tree, policy can only be published for the exact 93 domain. There is no method available to such domains to express 94 lower level policy or receive feedback reporting for sets of domains. 95 This prevents policy application to non-existent domains and 96 identification of domain abuse in email, which can be important for 97 brand and consumer protection. 99 As an example, imagine a country code TLD (ccTLD) which has public 100 subdomains for government and commercial use (.gov.example and 101 .com.example). Within the .gov.example public suffix, use of DMARC 102 [RFC7489] has been mandated and .gov.example has published its own 103 DMARC [RFC7489] record: 105 "v=DMARC1;p=reject;rua=mailto:dmarc@dmarc.service.gov.example" 107 at 109 _dmarc.gov.example. 111 This would provide policy and feedback for mail sent from 112 @gov.example, but not @tax.gov.example and there is no way to publish 113 an organizational level policy that would do so. While, in theory, 114 receivers could reject mail from non-existent domains, not all 115 receivers do so. Non-existence of the sending domain can be a factor 116 in a mail delivery decision, but is not generally treated as 117 definitive on its own. 119 This memo provides a simple extension to DMARC [RFC7489] to allow 120 operators of Public Suffix Domains (PSDs) to express policy for 121 groups of subdomains, extends the DMARC [RFC7489] policy query 122 functionality to detect and process such a policy, describes receiver 123 feedback for such policies, and provides controls to mitigate 124 potential privacy considerations associated with this extension. 126 There are two types of Public Suffix Operators (PSOs) for which this 127 extension would be useful and appropriate: 129 o Branded PSDs (e.g., ".google"): These domains are effectively 130 Organizational Domains as discussed in DMARC [RFC7489]. They 131 control all subdomains of the tree. These are effectively private 132 domains, but listed in the Public Suffix List. They are treated 133 as Public for DMARC [RFC7489] purposes. They require the same 134 protections as DMARC [RFC7489] Organizational Domains, but are 135 currently excluded. 137 o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): 138 Because existing Organizational Domains using this PSD have their 139 own DMARC policy, the applicability of this extension is for non- 140 existent domains. The extension allows the brand protection 141 benefits of DMARC [RFC7489] to extend to the entire PSD, including 142 cousin domains of registered organizations. 144 Due to the design of DMARC [RFC7489] and the nature of the Internet 145 email architecture [RFC5598], there are interoperability issues 146 associated with DMARC [RFC7489] deployment. These are discussed in 147 Interoperability Issues between DMARC and Indirect Email Flows 148 [RFC7960]. These issues are not applicable to PSDs, since they 149 (e.g., the ".gov.example" used above) do not send mail. 151 DMARC [RFC7489], by design, does not support usage by PSOs. For PSDs 152 that require use of DMARC [RFC7489], an extension of DMARC reporting 153 and enforcement capability is needed for PSO to effectively manage 154 and monitor implementation of PSD requirements. 156 2. Terminology and Definitions 158 This section defines terms used in the rest of the document. 160 2.1. Conventions Used in This Document 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in 165 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 166 capitals, as shown here. 168 2.2. Public Suffix Domain (PSD) 170 The global Internet Domain Name System (DNS) is documented in 171 numerous Requests for Comment (RFC). It defines a tree of names 172 starting with root, ".", immediately below which are Top Level Domain 173 names such as ".com" and ".us". They are not available for private 174 registration. In many cases the public portion of the DNS tree is 175 more than one level deep. PSD DMARC includes all public domains 176 above the organizational level in the tree, e.g., ".gov.uk". 178 2.3. Longest PSD 180 Organizational Domain (DMARC [RFC7489] Section 3.2) with one label 181 removed. 183 2.4. Public Suffix Operator (PSO) 185 A Public Suffix Operator manages operations within their PSD. 187 2.5. PSO Controlled Domain Names 189 PSO Controlled Domain Names are names in the DNS that are managed by 190 a PSO and are not available for use as Organizational Domains (the 191 term Organizational Domains is defined in DMARC [RFC7489] 192 Section 3.2). Depending on PSD policy, these will have one (e.g., 193 ".com") or more (e.g., ".co.uk") name components. 195 2.6. Non-existent Domains 197 For DMARC [RFC7489] purposes, a non-existent domain is a domain name 198 that publishes none of A, AAAA, or MX records that the receiver is 199 willing to accept. This is a broader definition than that in 200 NXDOMAIN [RFC8020]. 202 3. PSD DMARC Updates to DMARC Requirements 204 This document updates DMARC [RFC7489] as follows: 206 3.1. General Updates 208 References to "Domain Owners" also apply to PSOs. 210 3.2. Section 6.1 DMARC Policy Record 212 PSD DMARC records are published as a subdomain of the PSD. For the 213 PSD ".example", the PSO would post DMARC policy in a TXT record at 214 "_dmarc.example". 216 3.3. Section 6.5. Domain Owner Actions 218 In addition to the DMARC [RFC7489] domain owner actions, PSOs that 219 require use of DMARC ought to make that information available to 220 receivers. 222 3.4. Section 6.6.3. Policy Discovery 224 A new step between step 3 and 4 is added: 226 3A. If the set is now empty and the longest PSD (Section 2.3) of the 227 Organizational Domain is one that the receiver has determined is 228 acceptable for PSD DMARC, the Mail Receiver MUST query the DNS for 229 a DMARC TXT record at the DNS domain matching the longest PSD 230 (Section 2.3) in place of the RFC5322.From domain in the message 231 (if different). A possibly empty set of records is returned. 233 As an example, for a message with the Organizational Domain of 234 "example.compute.cloudcompany.com.cctld", the query for PSD DMARC 235 would use "compute.cloudcompany.com.cctld" as the longest PSD 236 (Section 2.3). The receiver would check to see if that PSD is listed 237 in the DMARC PSD Registry, and if so, perform the policy lookup at 238 "_dmarc.compute.cloudcompany.com.cctld". 240 Note: Because the PSD policy query comes after the Organizational 241 Domain policy query, PSD policy is not used for Organizational 242 domains that have published a DMARC [RFC7489] policy. Specifically, 243 this is not a mechanism to provide feedback addresses (RUA/RUF) when 244 an Organizational Domain has declined to do so. 246 3.5. Section 7. DMARC Feedback 248 Operational note for PSD DMARC: For PSOs, feedback for non-existent 249 domains is desired and useful. See Section 4 for discussion of 250 Privacy Considerations. 252 4. Privacy Considerations 254 These privacy considerations are developed based on the requiremetns 255 of [RFC6973]. The Privacy Considerations of [RFC7489] apply to this 256 document. 258 4.1. Feedback leakage 260 Providing feedback reporting to PSOs can, in some cases, create 261 leakage of information outside of an organization to the PSO. This 262 leakage could be potentially be utilized as part of a program of 263 pervasive surveillance (See [RFC7624]). There are roughly three 264 cases to consider: 266 o Single Organization PSDs (e.g., ".google"), RUA and RUF reports 267 based on PSD DMARC have the potential to contain information about 268 emails related to entities managed by the organization. Since 269 both the PSO and the Organizational Domain owners are common, 270 there is no additional privacy risk for either normal or non- 271 existent Domain reporting due to PSD DMARC. 273 o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): 274 PSD DMARC based reports will only be generated for domains that do 275 not publish a DMARC policy at the organizational or host level. 276 For domains that do publish the required DMARC policy records, the 277 feedback reporting addresses (RUA and RUF) of the organization (or 278 hosts) will be used. The only direct feedback leakage risk for 279 these PSDs are for Organizational Domains that are out of 280 compliance with PSD policy. Data on non-existent cousin domains 281 would be sent to the PSO. 283 o Multi-organization PSDs (e.g., ".com") that do not mandate DMARC 284 usage. Privacy risks for Organizational Domains that have not 285 deployed DMARC within such PSDs are significant. For non-DMARC 286 Organizational Domains, all DMARC feedback will be directed to the 287 PSO. PSD DMARC is opt-out (by publishing a DMARC record at the 288 Organizational Domain level) vice opt-in, which would be the more 289 desirable characteristic. 291 PSOs will receive feedback on non-existent domains, which may be 292 similar to existing Organizational Domains. Feedback related to such 293 cousin domains have a small risk of carrying information related to 294 an actual Organizational Domain. To minimize this potential concern, 295 PSD DMARC feedback is best limited to Aggregate Reports. Feedback 296 Reports carry more detailed information and present a greater risk. 298 Due to the inherent Privacy and Security risks associated with PSD 299 DMARC for Organizational Domains in multi-organization PSDs that do 300 not particpate in DMARC, any Feedback Reporting related to multi- 301 organizational PSDs ought to be limited to non-existent domains 302 except in cases where the reporter knows that PSO requires use of 303 DMARC. 305 5. Security Considerations 307 This document does not change the Security Considerations of 308 [RFC7489] and [RFC7960]. 310 The risks of the issues identified in [RFC7489], Section 12.5, 311 External Reporting Addresses, are amplified by PSD DMARC. By design, 312 PSD DMARC causes unrequested reporting of feedback to entities 313 external to the Organizational Domain. This is discussed in more 314 detail in Section 4. 316 6. IANA Considerations 318 This document does not require any IANA actions. 320 7. References 322 7.1. Normative References 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, 326 DOI 10.17487/RFC2119, March 1997, 327 . 329 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 330 Message Authentication, Reporting, and Conformance 331 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 332 . 334 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 335 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 336 May 2017, . 338 7.2. Informative References 340 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 341 DOI 10.17487/RFC5598, July 2009, 342 . 344 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 345 Morris, J., Hansen, M., and R. Smith, "Privacy 346 Considerations for Internet Protocols", RFC 6973, 347 DOI 10.17487/RFC6973, July 2013, 348 . 350 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 351 Trammell, B., Huitema, C., and D. Borkmann, 352 "Confidentiality in the Face of Pervasive Surveillance: A 353 Threat Model and Problem Statement", RFC 7624, 354 DOI 10.17487/RFC7624, August 2015, 355 . 357 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, 358 E., Ed., and K. Andersen, Ed., "Interoperability Issues 359 between Domain-based Message Authentication, Reporting, 360 and Conformance (DMARC) and Indirect Email Flows", 361 RFC 7960, DOI 10.17487/RFC7960, September 2016, 362 . 364 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is 365 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, 366 November 2016, . 368 Acknowledgements 370 TBS 372 Author's Address 373 Scott Kitterman 374 fTLD Registry Services 375 600 13th Street, NW, Suite 400 376 Washington, DC 20005 377 United States of America 379 Phone: +1 301 325-5475 380 Email: scott@kitterman.com