idnits 2.17.1 draft-ietf-dmarc-psd-00.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 (November 21, 2018) is 1982 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 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) November 21, 2018 5 Intended status: Informational 6 Expires: May 25, 2019 8 DMARC (Domain-based Message Authentication, Reporting, and Conformance) 9 Extension For PSDs (Public Suffix Domains) 10 draft-ietf-dmarc-psd-00 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 May 25, 2019. 45 Copyright Notice 47 Copyright (c) 2018 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 6.1. DMARC Public Suffix Domain (PSD) Registry 7 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 83 7.2. Informative References . . . . . . . . . . . . . . . . . 8 84 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 87 1. Introduction 89 DMARC [RFC7489] provides a mechanism for publishing organizational 90 policy information to email receivers. DMARC [RFC7489] allows policy 91 to be specified for both individual domains and sets of domains 92 within a single organization. For domains above the organizational 93 level in the DNS tree, policy can only be published for the exact 94 domain. There is no method available to such domains to express 95 lower level policy or receive feedback reporting for sets of domains. 96 This prevents policy application to non-existent domains and 97 identification of domain abuse in email, which can be important for 98 brand and consumer protection. 100 As an example, imagine a country code TLD (ccTLD) which has public 101 subdomains for government and commercial use (.gov.example and 102 .com.example). Within the .gov.example public suffix, use of DMARC 103 [RFC7489] has been mandated and .gov.example has published its own 104 DMARC [RFC7489] record: 106 "v=DMARC1;p=reject;rua=mailto:dmarc@dmarc.service.gov.example" 108 at 110 _dmarc.gov.example. 112 This would provide policy and feedback for mail sent from 113 @gov.example, but not @tax.gov.example and there is no way to publish 114 an organizational level policy that would do so. While, in theory, 115 receivers could reject mail from non-existent domains, not all 116 receivers do so. Non-existence of the sending domain can be a factor 117 in a mail delivery decision, but is not generally treated as 118 definitive on its own. 120 This memo provides a simple extension to DMARC [RFC7489] to allow 121 operators of Public Suffix Domains (PSDs) to express policy for 122 groups of subdomains, extends the DMARC [RFC7489] policy query 123 functionality to detect and process such a policy, describes receiver 124 feedback for such policies, and provides controls to mitigate 125 potential privacy considerations associated with this extension. 127 There are two types of Public Suffix Operators (PSOs) for which this 128 extension would be useful and appropriate: 130 o Branded PSDs (e.g., ".google"): These domains are effectively 131 Organizational Domains as discussed in DMARC [RFC7489]. They 132 control all subdomains of the tree. These are effectively private 133 domains, but listed in the Public Suffix List. They are treated 134 as Public for DMARC [RFC7489] purposes. They require the same 135 protections as DMARC [RFC7489] Organizational Domains, but are 136 currently excluded. 138 o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): 139 Because existing Organizational Domains using this PSD have their 140 own DMARC policy, the applicability of this extension is for non- 141 existent domains. The extension allows the brand protection 142 benefits of DMARC [RFC7489] to extend to the entire PSD, including 143 cousin domains of registered organizations. 145 Due to the design of DMARC [RFC7489] and the nature of the Internet 146 email architecture [RFC5598], there are interoperability issues 147 associated with DMARC [RFC7489] deployment. These are discussed in 148 Interoperability Issues between DMARC and Indirect Email Flows 149 [RFC7960]. These issues are not applicable to PSDs, since they 150 (e.g., the ".gov.example" used above) do not send mail. 152 DMARC [RFC7489], by design, does not support usage by PSD operators. 153 For PSDs that require use of DMARC [RFC7489], an extension of DMARC 154 reporting and enforcement capability is needed for PSD operators to 155 effectively manage and monitor implementation of PSD requirements. 157 2. Terminology and Definitions 159 This section defines terms used in the rest of the document. 161 2.1. Conventions Used in This Document 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 165 "OPTIONAL" in this document are to be interpreted as described in 166 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 167 capitals, as shown here. 169 2.2. Public Suffix Domain (PSD) 171 The global Internet Domain Name System (DNS) is documented in 172 numerous Requests for Comment (RFC). It defines a tree of names 173 starting with root, ".", immediately below which are Top Level Domain 174 names such as ".com" and ".us". They are not available for private 175 registration. In many cases the public portion of the DNS tree is 176 more than one level deep. PSD DMARC includes all public domains 177 above the organizational level in the tree, e.g., ".gov.uk". 179 2.3. Longest PSD 181 Organizational Domain (DMARC [RFC7489] Section 3.2) with one label 182 removed. 184 2.4. Public Suffix Operator (PSO) 186 A Public Suffix Operator manages operations within their PSD. 188 2.5. PSO Controlled Domain Names 190 PSO Controlled Domain Names are names in the DNS that are managed by 191 a PSO and are not available for use as Organizational Domains (the 192 term Organizational Domains is defined in DMARC [RFC7489] 193 Section 3.2). Depending on PSD policy, these will have one (e.g., 194 ".com") or more (e.g., ".co.uk") name components. 196 2.6. Non-existent Domains 198 For DMARC [RFC7489] purposes, a non-existent domain is a domain name 199 that publishes none of A, AAAA, or MX records that the receiver is 200 willing to accept. This is a broader definition than that in 201 NXDOMAIN [RFC8020]. 203 3. PSD DMARC Updates to DMARC Requirements 205 This document updates DMARC [RFC7489] as follows: 207 3.1. General Updates 209 References to "Domain Owners" also apply to PSOs. 211 3.2. Section 6.1 DMARC Policy Record 213 PSD DMARC records are published as a subdomain of the PSD. For the 214 PSD ".example", the PSO would post DMARC policy in a TXT record at 215 "_dmarc.example". 217 3.3. Section 6.5. Domain Owner Actions 219 In addition to the DMARC [RFC7489] domain owner actions, PSOs will 220 need to update the "DMARC Public Suffix Domain (PSD) Registry". This 221 registry is defined in Section 6.1. 223 3.4. Section 6.6.3. Policy Discovery 225 A new step between step 3 and 4 is added: 227 3A. If the set is now empty and the longest PSD (Section 2.3) of the 228 Organizational Domain is listed in the DMARC PSD Registry (defined 229 in Section 6.1), the Mail Receiver MUST query the DNS for a DMARC 230 TXT record at the DNS domain matching the longest PSD 231 (Section 2.3) in place of the RFC5322.From domain in the message 232 (if different). A possibly empty set of records is returned. 234 As an example, for a message with the Organizational Domain of 235 "example.compute.cloudcompany.com.cctld", the query for PSD DMARC 236 would use "compute.cloudcompany.com.cctld" as the longest PSD 237 (Section 2.3). The receiver would check to see if that PSD is listed 238 in the DMARC PSD Registry, and if so, perform the policy lookup at 239 "_dmarc.compute.cloudcompany.com.cctld". 241 Note: Because the PSD policy query comes after the Organizational 242 Domain policy query, PSD policy is not used for Organizational 243 domains that have published a DMARC [RFC7489] policy. Specifically, 244 this is not a mechanism to provide feedback addresses (RUA/RUF) when 245 an Organizational Domain has declined to do so. 247 3.5. Section 7. DMARC Feedback 249 Operational note for PSD DMARC: For PSOs, feedback for non-existent 250 domains is desired and useful. Because of the constraints on PSD 251 DMARC scope, there are no significant privacy considerations 252 associated with this reporting (See Section 4). 254 4. Privacy Considerations 256 This document does not significantly change the Privacy 257 Considerations of [RFC7489]. 259 4.1. Feedback leakage 261 Providing feedback reporting to PSOs can, in some cases, create 262 leakage of information outside of an organization to the PSO. There 263 are roughly three cases to consider: 265 o Branded PSDs (e.g., ".google"), RUA and RUF reports based on PSD 266 DMARC have the potential to contain information about emails 267 related to entities managed by the organization. Since both the 268 PSO and the Organizational Domain owners are common, there is no 269 privacy risk for either normal or non-existent Domain reporting. 271 o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): 272 PSD DMARC based reports will only be generated for domains that do 273 not publish a DMARC policy at the organizational or host level. 274 For domains that do publish the required DMARC policy records, the 275 feedback reporting addresses (RUA and RUF) of the organization (or 276 hosts) will be used. Since PSD DMARC is limited to PSDs that 277 mandate Organizational Domains publish DMARC policy for existing 278 domains, the risk of this issue is limited to Organizational 279 Domains that are out of compliance with PSD policy. 281 o Multi-organization PSDs (e.g., ".com") that do not mandate DMARC 282 usage. Privacy risks for Organizational Domains within such PSDs 283 would be significant. This is mitigated by the limitation to only 284 include PSDs listed in the public IANA DMARC PSD Registry 285 described in Section 6.1. 287 PSOs will receive feedback on non-existent domains, which may be 288 similar to existing Organizational Domains. Feedback related to such 289 cousin domains have a small risk of carrying information related to 290 an actual Organizational Domain. To minimize this potential concern, 291 PSD DMARC feedback is best limited to Aggregate Reports. Feedback 292 Reports carry more detailed information and present a greater risk. 294 5. Security Considerations 296 This document does not change the Security Considerations of 297 [RFC7489]. 299 6. IANA Considerations 301 This section describes actions requested to be completed by IANA. 303 6.1. DMARC Public Suffix Domain (PSD) Registry 305 IANA is requested to create a new DMARC Public Suffix Domain (PSD) 306 Registry within the Domain-based Message Authentication, Reporting, 307 and Conformance (DMARC) Parameters Registry. 309 Names of PSDs participating in PSD DMARC must be registered with IANA 310 in this new sub-registry. New entries are assigned only for PSDs 311 that require use of DMARC. The requirement has to be documented in a 312 manner that satisfies the terms of Expert Review, per [RFC5226]. The 313 Designated Expert needs to confirm that provided documentation 314 adequately describes PSD policy to require domain owners to use DMARC 315 or that all domain owners are part of a single organization with the 316 PSO. 318 The initial set of entries in this registry is as follows: 320 +-------------+----------------+---------------+ 321 | PSD | Reference | Status | 322 +-------------+----------------+---------------+ 323 | .bank | this document | current | 324 +-------------+----------------+---------------+ 325 | .insurance | this document | current | 326 +-------------+----------------+---------------+ 327 | .gov.uk | this document | current | 328 +-------------+----------------+---------------+ 330 7. References 332 7.1. Normative References 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, 336 DOI 10.17487/RFC2119, March 1997, 337 . 339 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 340 Message Authentication, Reporting, and Conformance 341 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 342 . 344 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 345 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 346 May 2017, . 348 7.2. Informative References 350 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 351 IANA Considerations Section in RFCs", RFC 5226, 352 DOI 10.17487/RFC5226, May 2008, 353 . 355 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 356 DOI 10.17487/RFC5598, July 2009, 357 . 359 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, 360 E., Ed., and K. Andersen, Ed., "Interoperability Issues 361 between Domain-based Message Authentication, Reporting, 362 and Conformance (DMARC) and Indirect Email Flows", 363 RFC 7960, DOI 10.17487/RFC7960, September 2016, 364 . 366 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is 367 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, 368 November 2016, . 370 Acknowledgements 372 TBS 374 Author's Address 376 Scott Kitterman 377 fTLD Registry Services 378 600 13th Street, NW, Suite 400 379 Washington, DC 20005 380 United States of America 382 Phone: +1 301 325-5475 383 Email: scott@kitterman.com