idnits 2.17.1 draft-ietf-dmarc-psd-07.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 (October 14, 2019) is 1654 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 October 14, 2019 5 Expires: April 16, 2020 7 DMARC (Domain-based Message Authentication, Reporting, and Conformance) 8 Extension For PSDs (Public Suffix Domains) 9 draft-ietf-dmarc-psd-07 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. The design of DMARC 18 presumes that domain names represent either nodes in the tree below 19 which registrations occur, or nodes where registrations have 20 occurred; it does not permit a domain name to have both of these 21 properties simultaneously. Since its deployment in 2015, use of 22 DMARC has shown a clear need for the ability to express policy for 23 these domains as well. 25 Domains at which registrations can occur are referred to as Public 26 Suffix Domains (PSDs). This document describes an extension to DMARC 27 to enable DMARC functionality for PSDs. 29 This document also seeks to address implementations that consider a 30 domain on a public Suffix list to be ineligible for DMARC 31 enforcement. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 16, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 69 2.1. Conventions Used in This Document . . . . . . . . . . . . 5 70 2.2. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 5 71 2.3. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 5 72 2.4. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 5 73 2.5. PSO Controlled Domain Names . . . . . . . . . . . . . . . 6 74 2.6. Non-existent Domains . . . . . . . . . . . . . . . . . . 6 75 3. PSD DMARC Updates to DMARC Requirements . . . . . . . . . . . 6 76 3.1. General Updates . . . . . . . . . . . . . . . . . . . . . 6 77 3.2. Section 6.3 General Record Format . . . . . . . . . . . . 6 78 3.3. Section 6.5. Domain Owner Actions . . . . . . . . . . . 7 79 3.4. Section 6.6.1. Extract Author Domain . . . . . . . . . . 7 80 3.5. Section 6.6.3. Policy Discovery . . . . . . . . . . . . 7 81 3.6. Section 7. DMARC Feedback . . . . . . . . . . . . . . . 8 82 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 83 4.1. Feedback leakage . . . . . . . . . . . . . . . . . . . . 8 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 86 6.1. Subdomain Policy Tag . . . . . . . . . . . . . . . . . . 9 87 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 89 7.2. Informative References . . . . . . . . . . . . . . . . . 10 90 Appendix A. The Experiment . . . . . . . . . . . . . . . . . . . 11 91 A.1. PSD DMARC Privacy Concern Mitigation . . . . . . . . . . 11 92 A.2. Non-Existent Subdomain Policy . . . . . . . . . . . . . . 12 93 Appendix B. DMARC PSD Registry Examples . . . . . . . . . . . . 12 94 B.1. DMARC PSD DNS Query Service . . . . . . . . . . . . . . . 13 95 B.2. DMARC Public Suffix Domain (PSD) Registry . . . . . . . . 13 96 B.3. DMARC PSD PSL Extension . . . . . . . . . . . . . . . . . 13 97 Appendix C. Implementations . . . . . . . . . . . . . . . . . . 14 98 C.1. Authheaders Module . . . . . . . . . . . . . . . . . . . 14 99 C.2. Zdkimfilter Module . . . . . . . . . . . . . . . . . . . 14 100 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 103 1. Introduction 105 DMARC [RFC7489] provides a mechanism for publishing organizational 106 policy information to email receivers. DMARC allows policy to be 107 specified for both individual domains and for organizational domains 108 and their sub-domains within a single organization. DMARC leverages 109 public suffix lists to determine which domains are organizational 110 domains. It presumes that public suffix list listed domains are not 111 organizational domains and not subject to DMARC processing; domains 112 are either organizational domains, sub-domains of organizational 113 domains, or listed on a public suffix list. For domains listed in a 114 public suffix list, i.e. TLDs and domains that exist between TLDs and 115 organization level domains, policy can only be published for the 116 exact domain. No method is available for these domains to express 117 policy or receive feedback reporting for sub-domains. This missing 118 method allows for the abuse of non-existent organizational-level 119 domains and prevents identification of domain abuse in email. 121 As an example, imagine a country code TLD (ccTLD) which has public 122 subdomains for government and commercial use (.gov.example and 123 .com.example). Suppose there exists a registered domain 124 "tax.gov.example" that is responsible for taxation in this imagined 125 country. However, by exploiting the typically unauthenticated nature 126 of email, there are regular malicious campaigns to impersonate this 127 organization that use similar-looking ("cousin") domains such as 128 "t4x.gov.example". These domains are not registered. Within the 129 ".gov.example" public suffix, use of DMARC has been mandated, so 130 "gov.example" publishes the following DMARC record: 132 "v=DMARC1; p=reject; rua=mailto:dmarc@dmarc.service.gov.example" 134 at 136 _dmarc.gov.example. 138 This DMARC record provides policy and a reporting destination for 139 mail sent from @gov.example. However, due to DMARC's current method 140 of discovering and applying policy at the organizational domain 141 level, the non-existent organizational domain of @tax.gov.example 142 does not and cannot fall under a DMARC policy. 144 Defensively registering all variants of "tax" is obviously not a 145 scalable strategy. The intent of this specification, therefore, is 146 to enhance the DMARC algorithm by enabling an agent receiving such a 147 message to be able to determine that a relevant policy is present at 148 "gov.example", which is precluded by the current DMARC algorithm. 150 This document provides a simple extension to DMARC [RFC7489] to allow 151 operators of Public Suffix Domains (PSDs) to express policy at the 152 level of the PSD that covers all organizational domains that do not 153 explicitly publish DMARC records, extends the DMARC policy query 154 functionality to detect and process such a policy, describes receiver 155 feedback for such policies, and provides controls to mitigate 156 potential privacy considerations associated with this extension. 158 This document also provides a new DMARC [RFC7489] tag to indicate 159 requested handling policy for non-existent subdommains. This is 160 provided specifically to support phased deployment of PSD DMARC, but 161 is expected to be useful more generally. Undesired rejection risks 162 for mail purporting to be from domains that do not exist are 163 substantially lower than for those that do, so the operational risk 164 of requesting harsh policy treatment (e.g. reject) is lower. 166 As an additional benefit, the PSD DMARC extension clarifies existing 167 requirements. Based on the requirements of DMARC [RFC7489], DMARC 168 should function above the organizational level for exact domain 169 matches (i.e. if a DMARC record were published for 'example', then 170 mail from example@example should be subject to DMARC processing). 171 Testing had revealed that this is not consistently applied in 172 different implementations. 174 There are two types of Public Suffix Operators (PSOs) for which this 175 extension would be useful and appropriate: 177 o Branded PSDs (e.g., ".google"): These domains are effectively 178 Organizational Domains as discussed in DMARC [RFC7489]. They 179 control all subdomains of the tree. These are effectively private 180 domains, but listed in the Public Suffix List. They are treated 181 as Public for DMARC purposes. They require the same protections 182 as DMARC Organizational Domains, but are currently unable to 183 benefit from DMARC. 185 o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): 186 Because existing Organizational Domains using this PSD have their 187 own DMARC policy, the applicability of this extension is for non- 188 existent domains. The extension allows the brand protection 189 benefits of DMARC to extend to the entire PSD, including cousin 190 domains of registered organizations. 192 Due to the design of DMARC [RFC7489] and the nature of the Internet 193 email architecture [RFC5598], there are interoperability issues 194 associated with DMARC [RFC7489] deployment. These are discussed in 195 Interoperability Issues between DMARC and Indirect Email Flows 196 [RFC7960]. These issues are not typically applicable to PSDs, since 197 they (e.g., the ".gov.example" used above) do not typically send 198 mail. 200 2. Terminology and Definitions 202 This section defines terms used in the rest of the document. 204 2.1. Conventions Used in This Document 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 208 "OPTIONAL" in this document are to be interpreted as described in 209 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 210 capitals, as shown here. 212 2.2. Public Suffix Domain (PSD) 214 The global Internet Domain Name System (DNS) is documented in 215 numerous Requests for Comment (RFC). It defines a tree of names 216 starting with root, ".", immediately below which are Top Level Domain 217 names such as ".com" and ".us". They are not available for private 218 registration. In many cases the public portion of the DNS tree is 219 more than one level deep. The domain name structure consists of a 220 tree of names, each of which is made of a sequence of words 221 ("labels") separated by period characters. The root of the tree is 222 simply called ".". The Internet community at large, through 223 processes and policies external to this work, selects points in this 224 tree at which to register domain names "owned" by independent 225 organizations. Real-world examples are ".com", ".org", ".us", and 226 ".gov.uk". Names at which such registrations occur are called Public 227 Suffix Domains (PSDs), and a registration consists of a label 228 selected by the registrant to which a desirable PSD is appended. For 229 example, "ietf.org" is a registered domain name, and ".org" is its 230 PSD. 232 2.3. Longest PSD 234 The longest PSD is the Organizational Domain with one label removed. 236 2.4. Public Suffix Operator (PSO) 238 A Public Suffix Operator manages operations within its PSD. 240 2.5. PSO Controlled Domain Names 242 PSO Controlled Domain Names are names in the DNS that are managed by 243 a PSO and are not available for use as Organizational Domains (the 244 term Organizational Domains is defined in DMARC [RFC7489] 245 Section 3.2). Depending on PSD policy, these will have one (e.g., 246 ".com") or more (e.g., ".co.uk") name components. 248 2.6. Non-existent Domains 250 For DMARC purposes, a non-existent domain is a domain for which there 251 is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This 252 is a broader definition than that in NXDOMAIN [RFC8020]. 254 3. PSD DMARC Updates to DMARC Requirements 256 This document updates DMARC [RFC7489] as follows: 258 3.1. General Updates 260 References to "Domain Owners" also apply to PSOs. 262 3.2. Section 6.3 General Record Format 264 A new tag is added after "fo": 266 np: Requested Mail Receiver policy for non-existent subdomains 267 (plain-text; OPTIONAL). Indicates the policy to be enacted by the 268 Receiver at the request of the Domain Owner. It applies only to 269 non-existent subdomains of the domain queried and not to either 270 existing subdomains or the domain itself. Its syntax is identical 271 to that of the "p" tag defined below. If the 'np' tag is absent, 272 the policy specified by the "sp" tag (if the 'sp' tag is present) 273 or the policy specified by the "p" tag, if the 'sp' tag is not 274 present, MUST be applied for non-existent subdomains. Note that 275 "np" will be ignored for DMARC records published on subdomains of 276 Organizational Domains and PSDs due to the effect of the DMARC 277 policy discovery mechanism described in DMARC [RFC7489] 278 Section 6.6.3. 280 The following tag definitions from DMARC [RFC7489] are updated: 282 p: The sentence 'Policy applies to the domain queried and to 283 subdomains, unless subdomain policy is explicitly described using 284 the "sp" tag' is updated to read 'Policy applies to the domain 285 queried and to subdomains, unless subdomain policy is explicitly 286 described using the "sp" or "np" tags.' 288 sp: The sentence 'If absent, the policy specified by the "p" tag 289 MUST be applied for subdomains' is updated to read 'If both the 290 'sp' tag is absent and the 'np' tag is either absent or not 291 applicable, the policy specified by the "p" tag MUST be applied 292 for subdomains. 294 3.3. Section 6.5. Domain Owner Actions 296 In addition to the DMARC domain owner actions, PSOs that require use 297 of DMARC and participate in PSD DMARC ought to make that information 298 available to receivers. The mechanism for doing so is one of the 299 experimental elements of this document. See the experiment 300 description (Appendix A). 302 3.4. Section 6.6.1. Extract Author Domain 304 Experience with DMARC has shown that some implementations short- 305 circuit messages, bypassing DMARC policy application, when the domain 306 name extracted by the receiver (from the RFC5322.From) is on the 307 public suffix list used by the receiver. This negates the capability 308 being created by this specification. Therefore, the following 309 paragraph is appended to Section 6.6.1 of DMARC [RFC7489]: 311 Note that domain names that appear on a public suffix list are not 312 exempt from DMARC policy application and reporting. 314 3.5. Section 6.6.3. Policy Discovery 316 A new step between step 3 and 4 is added: 318 3A. If the set is now empty and the longest PSD (Section 2.3) of the 319 Organizational Domain is one that the receiver has determined is 320 acceptable for PSD DMARC (discussed in the experiment description 321 (Appendix A)), the Mail Receiver MUST query the DNS for a DMARC 322 TXT record at the DNS domain matching the longest PSD 323 (Section 2.3) in place of the RFC5322.From domain in the message 324 (if different). A possibly empty set of records is returned. 326 As an example, for a message with the Organizational Domain of 327 "example.compute.cloudcompany.com.example", the query for PSD DMARC 328 would use "compute.cloudcompany.com.example" as the longest PSD 329 (Section 2.3). The receiver would check to see if that PSD is listed 330 in the DMARC PSD Registry, and if so, perform the policy lookup at 331 "_dmarc.compute.cloudcompany.com.example". 333 Note: Because the PSD policy query comes after the Organizational 334 Domain policy query, PSD policy is not used for Organizational 335 domains that have published a DMARC policy. Specifically, this is 336 not a mechanism to provide feedback addresses (RUA/RUF) when an 337 Organizational Domain has declined to do so. 339 3.6. Section 7. DMARC Feedback 341 Operational note for PSD DMARC: For PSOs, feedback for non-existent 342 domains is desirable and useful, just as it is for org-level DMARC 343 operators. See Section 4 of this document for discussion of Privacy 344 Considerations. 346 4. Privacy Considerations 348 These privacy considerations are developed based on the requirements 349 of [RFC6973]. The Privacy Considerations of [RFC7489] apply to this 350 document. 352 4.1. Feedback leakage 354 Providing feedback reporting to PSOs can, in some cases, create 355 leakage of information outside of an organization to the PSO. This 356 leakage could potentially be utilized as part of a program of 357 pervasive surveillance (See [RFC7624]). There are roughly three 358 cases to consider: 360 o Single Organization PSDs (e.g., ".google"), RUA and RUF reports 361 based on PSD DMARC have the potential to contain information about 362 emails related to entities managed by the organization. Since 363 both the PSO and the Organizational Domain owners are common, 364 there is no additional privacy risk for either normal or non- 365 existent Domain reporting due to PSD DMARC. 367 o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): 368 PSD DMARC based reports will only be generated for domains that do 369 not publish a DMARC policy at the organizational or host level. 370 For domains that do publish the required DMARC policy records, the 371 feedback reporting addresses (RUA and RUF) of the organization (or 372 hosts) will be used. The only direct feedback leakage risk for 373 these PSDs are for Organizational Domains that are out of 374 compliance with PSD policy. Data on non-existent cousin domains 375 would be sent to the PSO. 377 o Multi-organization PSDs (e.g., ".com") that do not mandate DMARC 378 usage: Privacy risks for Organizational Domains that have not 379 deployed DMARC within such PSDs are significant. For non-DMARC 380 Organizational Domains, all DMARC feedback will be directed to the 381 PSO. PSD DMARC is opt-out (by publishing a DMARC record at the 382 Organizational Domain level) vice opt-in, which would be the more 383 desirable characteristic. This means that any non-DMARC 384 organizational domain would have its feedback reports redirected 385 to the PSO. The content of such reports, particularly for 386 existing domains, is privacy sensitive. 388 PSOs will receive feedback on non-existent domains, which may be 389 similar to existing Organizational Domains. Feedback related to such 390 cousin domains have a small risk of carrying information related to 391 an actual Organizational Domain. To minimize this potential concern, 392 PSD DMARC feedback is best limited to Aggregate Reports. Feedback 393 Reports carry more detailed information and present a greater risk. 395 Due to the inherent Privacy and Security risks associated with PSD 396 DMARC for Organizational Domains in multi-organization PSDs that do 397 not particpate in DMARC, any Feedback Reporting related to multi- 398 organizational PSDs ought to be limited to non-existent domains 399 except in cases where the reporter knows that PSO requires use of 400 DMARC. 402 5. Security Considerations 404 This document does not change the Security Considerations of 405 [RFC7489] and [RFC7960]. 407 The risks of the issues identified in [RFC7489], Section 12.3, DNS 408 Security, are amplified by PSD DMARC. In particular, DNS cache 409 poisoning (or Name Chaining), see [RFC3833] for details, consequences 410 are increased because a sucessful attack would potentially have a 411 much wider scope. 413 The risks of the issues identified in [RFC7489], Section 12.5, 414 External Reporting Addresses, are amplified by PSD DMARC. By design, 415 PSD DMARC causes unrequested reporting of feedback to entities 416 external to the Organizational Domain. This is discussed in more 417 detail in Section 4. 419 6. IANA Considerations 421 This section describes actions requested to be completed by IANA. 423 6.1. Subdomain Policy Tag 425 IANA is requested to add a new tag to DMARC Tag Registry in the 426 Domain-based Message Authentication, Reporting, and Conformance 427 (DMARC) Parameters Registry. 429 The entry is as follows: 431 +----------+-----------+---------+-------------------------------+ 432 | Tag Name | Reference | Status | Description | 433 +----------+-----------+---------+-------------------------------+ 434 | np | this | current | Requested handling policy for | 435 | | document | | non-existent subdomains | 436 +----------+-----------+---------+-------------------------------+ 438 7. References 440 7.1. Normative References 442 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 443 Requirement Levels", BCP 14, RFC 2119, 444 DOI 10.17487/RFC2119, March 1997, 445 . 447 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 448 Message Authentication, Reporting, and Conformance 449 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 450 . 452 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 453 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 454 May 2017, . 456 7.2. Informative References 458 [psddmarc.org] 459 multiple, "PSD DMARC Web Site", April 2019, 460 . 462 [PSL] multiple, "Public Suffix List", April 2019, 463 . 465 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 466 Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August 467 2004, . 469 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 470 IANA Considerations Section in RFCs", RFC 5226, 471 DOI 10.17487/RFC5226, May 2008, 472 . 474 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 475 DOI 10.17487/RFC5598, July 2009, 476 . 478 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 479 Morris, J., Hansen, M., and R. Smith, "Privacy 480 Considerations for Internet Protocols", RFC 6973, 481 DOI 10.17487/RFC6973, July 2013, 482 . 484 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 485 Trammell, B., Huitema, C., and D. Borkmann, 486 "Confidentiality in the Face of Pervasive Surveillance: A 487 Threat Model and Problem Statement", RFC 7624, 488 DOI 10.17487/RFC7624, August 2015, 489 . 491 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, 492 E., Ed., and K. Andersen, Ed., "Interoperability Issues 493 between Domain-based Message Authentication, Reporting, 494 and Conformance (DMARC) and Indirect Email Flows", 495 RFC 7960, DOI 10.17487/RFC7960, September 2016, 496 . 498 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is 499 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, 500 November 2016, . 502 Appendix A. The Experiment 504 There are two experimental questions addressed in this document: one 505 regarding mitigation of PSD related privacy concerns and the other on 506 the utility of specifying separate DMARC policies for non-existent 507 sub-domains. 509 Aditionally, as of the writing of this document operational and 510 policy constraints prevent this experiment from being deployed 511 globally. If the experiment shows that PSD DMARC solves a real 512 problem and can be used at a large scale, the results could prove to 513 be useful in removing constraints outside of the IETF that would 514 permit broader deployment. 516 A.1. PSD DMARC Privacy Concern Mitigation 518 To mitigate the privacy concerns associated with Multi-organization 519 PSDs that do not mandate DMARC usage, see Section 4.1, a mechanism to 520 indicate which PSDs do not present this privacy risk is appropriate. 521 There are multiple approaches that are possible. 523 The experiment is to evaluate different possible approaches. The 524 experiment will be complete when there is rough consensus on a 525 technical approach that is demonstrated to be operationally usable 526 and effective at mitigating the privacy concern. 528 The mechanism needs the following attributes: 530 o Be reliably, publicly accessible 532 o Be under configuration control based on a public set of criteria 534 o List PSDs that either mandate DMARC for their registrants or for 535 which all lower level domains are controlled by the PSO and that 536 the relevant PSO has indicated a desire for the PSD to participate 537 in PSD DMARC 539 o Have a small operational footprint (e.g. provide a documented, 540 lightweight mechanism for developers and operators to retrieve the 541 list of PSD DMARC participants) 543 o Not allow PSO to add PSDs to the PSD DMARC participants list 544 without third party review 546 As of this writing, three approaches have been proposed. None of 547 them are ideal: 549 o An extension to the Public Suffix List at [PSL] 551 o A dedicated registry queried via DNS - an example of such a 552 service is described in Appendix B.1 below 554 o An IANA registry 556 A.2. Non-Existent Subdomain Policy 558 PSOs that plan to implement PSD DMARC have indicated that the ability 559 to describe distinct policies for existing and non- existing sub- 560 domains would facilitate PSD DMARC deployment. There are also 561 suggestions that it would be more generally useful for DMARC. 563 During the period of the experiment, uptake of the new 'np' tag will 564 be evaluated to support assessment of the utility of including 'np' 565 in a future, non-experimental update. 567 Appendix B. DMARC PSD Registry Examples 569 To facilitate experimentation around data leakage mitigation, samples 570 of the DNS based and IANA like registries are available at 571 [psddmarc.org]. 573 B.1. DMARC PSD DNS Query Service 575 A sample stand-alone DNS query service is available at 576 [psddmarc.org]. It was developed based on the contents suggested for 577 an IANA registry in an earlier revision of this draft. Usage of the 578 service is described on the web site. 580 B.2. DMARC Public Suffix Domain (PSD) Registry 582 [psddmarc.org] provides an IANA like DMARC Public Suffix Domain (PSD) 583 Registry as a stand-alone DNS query service. It follows the contents 584 and structure described below. There is a Comma Separated Value 585 (CSV) version of the listed PSD domains which is suitable for use in 586 build updates for PSD DMARC capable software. 588 Names of PSDs participating in PSD DMARC must be registered this new 589 registry. New entries are assigned only for PSDs that require use of 590 DMARC. The requirement has to be documented in a manner that 591 satisfies the terms of Expert Review,per [RFC5226]. The Designated 592 Expert needs to confirm that provided documentation adequately 593 describes PSD policy to require domain owners to use DMARC or that 594 all domain owners are part of a single organization with the PSO. 596 The initial set of entries in this registry is as follows: 598 +-------------+---------------+ 599 | PSD | Status | 600 +-------------+---------------+ 601 | .bank | current | 602 +-------------+---------------+ 603 | .insurance | current | 604 +-------------+---------------+ 605 | .gov.uk | current | 606 +-------------+---------------+ 608 B.3. DMARC PSD PSL Extension 610 [psddmarc.org] provides a PSL like file to enable to facilitate 611 identification of PSD DMARC participants. Contents are functionally 612 identical to the IANA like registry, but presented in a different 613 format. 615 When using this approach, the input domain of the extension lookup is 616 supposed to be the output domain of the regular PSL lookup, i.e. the 617 organizational domain. This alternative data approach is potentially 618 useful since DMARC implementations already need to be able to parse 619 the data format, so it should be easier to implement. 621 Appendix C. Implementations 623 There are two known implementations of PSD DMARC available for 624 testing. 626 C.1. Authheaders Module 628 The authheaders Python module and command line tool is available for 629 download or installation from Pypi (Python Packaging Index). 631 It supports both use of the DNS based query service and download of 632 the CSV registry file from [psddmarc.org]. 634 C.2. Zdkimfilter Module 636 The zdkimfilter module is a separately available add-on to Courier- 637 MTA. 639 Mostly used for DKIM signing, it can be configured to also verify, 640 apply DMARC policies, and send aggregate reports. For PSD DMARC it 641 uses the PSL extension list approach, which is available from from 642 [psddmarc.org] 644 Acknowledgements 646 Thanks to the following individuals for their contributions (both 647 public and private) to improving this document. Special shout out to 648 Dave Crocker for naming the beast. 650 Kurt Andersen, Seth Blank, Dave Crocker, Heather Diaz, Tim Draegen, 651 Zeke Hendrickson, Andrew Kennedy, John Levine, Dr Ian Levy, Craig 652 Schwartz, Alessandro Vesely, and Tim Wicinski 654 Author's Address 656 Scott Kitterman 657 fTLD Registry Services 658 600 13th Street, NW, Suite 400 659 Washington, DC 20005 660 United States of America 662 Phone: +1 301 325-5475 663 Email: scott@kitterman.com