idnits 2.17.00 (12 Aug 2021) /tmp/idnits46010/draft-ietf-dmarc-psd-15.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 (June 14, 2021) is 334 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 548 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 T. Wicinski, Ed. 5 Expires: December 16, 2021 June 14, 2021 7 Experimental DMARC Extension For Public Suffix Domains 8 draft-ietf-dmarc-psd-15 10 Abstract 12 Domain-based Message Authentication, Reporting, and Conformance 13 (DMARC) permits a domain-controlling organization to express domain- 14 level policies and preferences for message validation, disposition, 15 and reporting, which a mail-receiving organization can use to improve 16 mail handling. 18 DMARC distinguishes the portion of a name that is a Public Suffix 19 Domain (PSD), below which organizational domain names are created. 20 The basic DMARC capability allows organizational domains to specify 21 policies that apply to their subdomains, but it does not give that 22 capability to PSDs. This document describes an extension to DMARC to 23 fully enable DMARC functionality for PSDs. 25 Some implementations of DMARC consider a PSD to be ineligible for 26 DMARC enforcement. This specification addresses that case. 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 December 16, 2021. 45 Copyright Notice 47 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Discussion . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 66 2.1. Conventions Used in This Document . . . . . . . . . . . . 5 67 2.2. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 6 68 2.3. Organizational Domain . . . . . . . . . . . . . . . . . . 6 69 2.4. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.5. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 6 71 2.6. PSO Controlled Domain Names . . . . . . . . . . . . . . . 6 72 2.7. Non-existent Domains . . . . . . . . . . . . . . . . . . 6 73 3. PSD DMARC Updates to DMARC Requirements . . . . . . . . . . . 7 74 3.1. General Updates . . . . . . . . . . . . . . . . . . . . . 7 75 3.2. Changes in Section 6.3 "General Record Format" . . . . . 7 76 3.3. Changes in Section 6.4 "Formal Definition" . . . . . . . 7 77 3.4. Changes in Section 6.5 "Domain Owner Actions" . . . . . . 8 78 3.5. Changes in Section 6.6.1 "Extract Author Domain" . . . . 8 79 3.6. Changes in Section 6.6.3 "Policy Discovery" . . . . . . . 8 80 3.7. Changes in Section 7 "DMARC Feedback" . . . . . . . . . . 9 81 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 6.1. Subdomain Policy Tag . . . . . . . . . . . . . . . . . . 11 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 87 7.2. Informative References . . . . . . . . . . . . . . . . . 11 88 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 Appendix A. PSD DMARC Privacy Concern Mitigation Experiment . . 12 90 Appendix B. DMARC PSD Registry Examples . . . . . . . . . . . . 13 91 B.1. DMARC PSD DNS Query Service . . . . . . . . . . . . . . . 13 92 B.2. DMARC Public Suffix Domain (PSD) Registry . . . . . . . . 13 93 B.3. DMARC PSD PSL Extension . . . . . . . . . . . . . . . . . 14 94 Appendix C. Implementations . . . . . . . . . . . . . . . . . . 14 95 C.1. Authheaders Module . . . . . . . . . . . . . . . . . . . 14 96 C.2. Zdkimfilter Module . . . . . . . . . . . . . . . . . . . 14 97 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 100 1. Introduction 102 DMARC [RFC7489] provides a mechanism for publishing organizational 103 policy information to email receivers. DMARC allows policy to be 104 specified for both individual domains and for organizational domains 105 and their sub-domains within a single organization. 107 To determine the organizational domain for a message under 108 evaluation, and thus where to look for a policy statement, DMARC 109 makes use of a public suffix list. The process for doing this can be 110 found in Section 3.2 of the DMARC specification. Currently, the 111 public suffix list being used is the most common one that is 112 maintained by the Mozilla Foundation and made public at 113 http://publicsuffix.org [1]. 115 In the basic DMARC model, Public Suffix Domains (PSDs) are not 116 organizational domains and are thus not subject to DMARC processing. 117 In DMARC, domains fall into one of three categories: organizational 118 domains, sub-domains of organizational domains, or PSDs. A PSD can 119 only publish DMARC policy for itself, and not for any sub-domains 120 under it. In some cases, this limitation allows for the abuse of 121 non-existent organizational-level domains and hampers identification 122 of domain abuse in email. 124 This document specifies experimental updates to the DMARC 125 specification cited above, in an attempt to mitigate this abuse. 127 1.1. Example 129 As an example, imagine a Top-Level Domain (TLD), ".example", that has 130 public subdomains for government and commercial use (".gov.example" 131 and ".com.example"). The maintainer of a list of such a PSD 132 structure would include entries for both of these sub-domains, 133 thereby indicating that they are PSDs, below which organizational 134 domains can be registered. Suppose further that there exists a 135 legitimate domain called "tax.gov.example", registered within 136 ".gov.example". 138 However, by exploiting the typically unauthenticated nature of email, 139 there are regular malicious campaigns to impersonate this 140 organization that use similar-looking ("cousin") domains such as 141 "t4x.gov.example". Such domains are not registered. 143 Within the ".gov.example" public suffix, use of DMARC has been 144 mandated, so "gov.example" publishes the following DMARC DNS record: 146 _dmarc.gov.example. IN TXT ( "v=DMARC1; p=reject;" 147 "rua=mailto:dmc@dmarc.svc.gov.example" ) 149 This DMARC record provides policy and a reporting destination for 150 mail sent from @gov.example. Similarly, "tax.gov.example" will have 151 a DMARC record that specifies policy for mail sent from addresses 152 @tax.gov.example. However, due to DMARC's current method of 153 discovering and applying policy at the organizational domain level, 154 the non-existent organizational domain of @t4x.gov.example does not 155 and cannot fall under a DMARC policy. 157 Defensively registering all variants of "tax" is not a scalable 158 strategy. The intent of this specification, therefore, is to enhance 159 the DMARC discovery method by enabling an agent receiving such a 160 message to be able to determine that a relevant policy is present at 161 "gov.example", which is precluded by the current DMARC specification. 163 1.2. Discussion 165 This document provides a simple extension to [RFC7489] to allow 166 operators of Public Suffix Domains (PSDs) to: 168 o Express policy at the level of the PSD that covers all 169 organizational domains that do not explicitly publish DMARC 170 records 172 o Extends the DMARC policy query functionality to detect and process 173 such a policy 175 o Describes receiver feedback for such policies 177 o Provides controls to mitigate potential privacy considerations 178 associated with this extension 180 This document also provides a new DMARC tag to indicate requested 181 handling policy for non-existent subdomains. This is provided 182 specifically to support phased deployment of PSD DMARC, but is 183 expected to be useful more generally. Undesired rejection risks for 184 mail purporting to be from domains that do not exist are 185 substantially lower than for those that do, so the operational risk 186 of requesting harsh policy treatment (e.g., reject) is lower. 188 As an additional benefit, the PSD DMARC extension clarifies existing 189 requirements. Based on the requirements of [RFC7489], DMARC should 190 function above the organizational level for exact domain matches 191 (i.e., if a DMARC record were published for "example", then mail from 192 example@example should be subject to DMARC processing). Testing had 193 revealed that this is not consistently applied in different 194 implementations. 196 There are two types of Public Suffix Operators (PSOs) for which this 197 extension would be useful and appropriate: 199 o Branded PSDs (e.g., ".google"): These domains are effectively 200 Organizational Domains as discussed in [RFC7489]. They control 201 all subdomains of the tree. These are effectively private 202 domains, but listed in the current public suffix list. They are 203 treated as Public for DMARC purposes. They require the same 204 protections as DMARC Organizational Domains, but are currently 205 unable to benefit from DMARC. 207 o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): 208 Because existing Organizational Domains using this PSD have their 209 own DMARC policy, the applicability of this extension is for non- 210 existent domains. The extension allows the brand protection 211 benefits of DMARC to extend to the entire PSD, including cousin 212 domains of registered organizations. 214 Due to the design of DMARC and the nature of the Internet email 215 architecture [RFC5598], there are interoperability issues associated 216 with DMARC deployment. These are discussed in Interoperability 217 Issues between DMARC and Indirect Email Flows [RFC7960]. These 218 issues are not typically applicable to PSDs, since they (e.g., the 219 ".gov.example" used above) do not typically send mail. 221 2. Terminology and Definitions 223 This section defines terms used in the rest of the document. 225 2.1. Conventions Used in This Document 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 229 "OPTIONAL" in this document are to be interpreted as described in 230 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 231 capitals, as shown here. 233 2.2. Public Suffix Domain (PSD) 235 The global Internet Domain Name System (DNS) is documented in 236 numerous RFCs. It defines a tree of names starting with root, ".", 237 immediately below which are Top Level Domain names such as ".com" and 238 ".us". The domain name structure consists of a tree of names, each 239 of which is made of a sequence of words ("labels") separated by 240 period characters. The root of the tree is simply called ".". The 241 Internet community at large, through processes and policies external 242 to this work, selects points in this tree at which to register domain 243 names "owned" by independent organizations. Real-world examples are 244 ".com", ".org", ".us", and ".gov.uk". Names at which such 245 registrations occur are called Public Suffix Domains (PSDs), and a 246 registration consists of a label selected by the registrant to which 247 a desirable PSD is appended. For example, "ietf.org" is a registered 248 domain name, and ".org" is its PSD. 250 2.3. Organizational Domain 252 The term Organizational Domains is defined in [RFC7489] Section 3.2. 254 2.4. Longest PSD 256 The longest PSD is the Organizational Domain with one label removed. 257 It names the immediate parent node of the Organizational Domain in 258 the DNS namespace tree. 260 2.5. Public Suffix Operator (PSO) 262 A Public Suffix Operator is an organization which manages operations 263 within a PSD, particularly the DNS records published for names at and 264 under that domain name. 266 2.6. PSO Controlled Domain Names 268 PSO Controlled Domain Names are names in the DNS that are managed by 269 a PSO and are not available for use as Organizational Domains. PSO 270 Controlled Domain Names may have one (e.g., ".com") or more (e.g., 271 ".co.uk") name components, depending on PSD policy. 273 2.7. Non-existent Domains 275 For DMARC purposes, a non-existent domain is a domain for which there 276 is an NXDOMAIN or NODATA response for A, AAAA, and MX records. This 277 is a broader definition than that in [RFC8020]. 279 3. PSD DMARC Updates to DMARC Requirements 281 To participate in this experiment, implementations should interpret 282 RFC7489 as follows: 284 3.1. General Updates 286 References to "Domain Owners" also apply to PSOs. 288 3.2. Changes in Section 6.3 "General Record Format" 290 If this experiment is successful, this paragraph is added to this 291 section. A new tag is added after "fo": 293 np: Requested Mail Receiver policy for non-existent subdomains 294 (plain-text; OPTIONAL). Indicates the policy to be enacted by the 295 Receiver at the request of the Domain Owner. It applies only to 296 non-existent subdomains of the domain queried and not to either 297 existing subdomains or the domain itself. Its syntax is identical 298 to that of the "p" tag defined below. If the "np" tag is absent, 299 the policy specified by the "sp" tag (if the "sp" tag is present) 300 or the policy specified by the "p" tag, if the "sp" tag is not 301 present, MUST be applied for non-existent subdomains. Note that 302 "np" will be ignored for DMARC records published on subdomains of 303 Organizational Domains and PSDs due to the effect of the DMARC 304 policy discovery mechanism described in DMARC Section 6.6.3. 306 The following tag definitions from DMARC are updated: 308 p: The sentence 'Policy applies to the domain queried and to 309 subdomains, unless subdomain policy is explicitly described using 310 the "sp" tag' is updated to read 'Policy applies to the domain 311 queried and to subdomains, unless subdomain policy is explicitly 312 described using the "sp" or "np" tags.' 314 sp: The sentence 'If absent, the policy specified by the "p" tag 315 MUST be applied for subdomains' is updated to read 'If both the 316 "sp" tag is absent and the "np" tag is either absent or not 317 applicable, the policy specified by the "p" tag MUST be applied 318 for subdomains. 320 3.3. Changes in Section 6.4 "Formal Definition" 322 The ABNF for DMARC shall updated to include a new definition "dmarc- 323 nprequest" which is defined as: 325 dmarc-nprequest = "np" *WSP "=" *WSP 326 ( "none" / "quarantine" / "reject" ) 328 The "dmarc-record" definition is also updated to include the 329 following: 331 [dmarc-sep dmarc-nprequest] 333 3.4. Changes in Section 6.5 "Domain Owner Actions" 335 In addition to the DMARC domain owner actions, PSOs that require use 336 of DMARC and participate in PSD DMARC ought to make that information 337 available to receivers. This document is an experimental mechanism 338 for doing so. See the [this document] experiment description 339 (Appendix A). 341 3.5. Changes in Section 6.6.1 "Extract Author Domain" 343 Experience with DMARC has shown that some implementations short- 344 circuit messages, bypassing DMARC policy application, when the domain 345 name extracted by the receiver (from the RFC5322.From) is on the 346 public suffix list used by the receiver. This negates the capability 347 being created by this specification. Therefore, the following 348 paragraph is appended to Section 6.6.1 of DMARC: 350 Note that domain names that appear on a public suffix list are not 351 exempt from DMARC policy application and reporting. 353 3.6. Changes in Section 6.6.3 "Policy Discovery" 355 A new step between step 3 and 4 is added: 357 3A. If the set is now empty and the longest PSD (Section 2.4) of the 358 Organizational Domain is one that the receiver has determined is 359 acceptable for PSD DMARC (discussed in the [this document] 360 experiment description (Appendix A)), the Mail Receiver MUST query 361 the DNS for a DMARC TXT record at the DNS domain matching the 362 [this document] longest PSD (Section 2.4) in place of the 363 RFC5322.From domain in the message (if different). A possibly 364 empty set of records is returned. 366 As an example, for a message with the Organizational Domain of 367 "example.compute.cloudcompany.com.example", the query for PSD DMARC 368 would use "compute.cloudcompany.com.example" as the [this document] 369 longest PSD (Section 2.4). The receiver would check to see if that 370 PSD is listed in the DMARC PSD Registry, and if so, perform the 371 policy lookup at "_dmarc.compute.cloudcompany.com.example". 373 Note: Because the PSD policy query comes after the Organizational 374 Domain policy query, PSD policy is not used for Organizational 375 domains that have published a DMARC policy. Specifically, this is 376 not a mechanism to provide feedback addresses (RUA/RUF) when an 377 Organizational Domain has declined to do so. 379 3.7. Changes in Section 7 "DMARC Feedback" 381 If this experiment is successful, this paragraph is added to this 382 section. 384 Operational note for PSD DMARC: For PSOs, feedback for non-existent 385 domains is desirable and useful, just as it is for org-level DMARC 386 operators. See Section 4 of [this document] for discussion of 387 Privacy Considerations for PSD DMARC. 389 4. Privacy Considerations 391 These privacy considerations are developed based on the requirements 392 of [RFC6973]. Additionally, the Privacy Considerations of [RFC7489] 393 apply to the mechanisms described by this document. If this 394 experiment is successful, this section should be incorporated into 395 the Privacy Considerations section as "Feedback leakage". 397 Providing feedback reporting to PSOs can, in some cases, cause 398 information to leak out of an organization to the PSO. This leakage 399 could potentially be utilized as part of a program of pervasive 400 surveillance (See [RFC7624]). There are roughly three cases to 401 consider: 403 o Single Organization PSDs (e.g., ".google"), RUA and RUF reports 404 based on PSD DMARC have the potential to contain information about 405 emails related to entities managed by the organization. Since 406 both the PSO and the Organizational Domain owners are common, 407 there is no additional privacy risk for either normal or non- 408 existent Domain reporting due to PSD DMARC. 410 o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): 411 PSD DMARC based reports will only be generated for domains that do 412 not publish a DMARC policy at the organizational or host level. 413 For domains that do publish the required DMARC policy records, the 414 feedback reporting addresses (RUA and RUF) of the organization (or 415 hosts) will be used. The only direct feedback leakage risk for 416 these PSDs are for Organizational Domains that are out of 417 compliance with PSD policy. Data on non-existent cousin domains 418 would be sent to the PSO. 420 o Multi-organization PSDs (e.g., ".com") that do not mandate DMARC 421 usage: Privacy risks for Organizational Domains that have not 422 deployed DMARC within such PSDs are significant. For non-DMARC 423 Organizational Domains, all DMARC feedback will be directed to the 424 PSO. PSD DMARC is opt-out (by publishing a DMARC record at the 425 Organizational Domain level) instead of opt-in, which would be the 426 more desirable characteristic. This means that any non-DMARC 427 organizational domain would have its feedback reports redirected 428 to the PSO. The content of such reports, particularly for 429 existing domains, is privacy sensitive. 431 PSOs will receive feedback on non-existent domains, which may be 432 similar to existing Organizational Domains. Feedback related to such 433 cousin domains have a small risk of carrying information related to 434 an actual Organizational Domain. To minimize this potential concern, 435 PSD DMARC feedback MUST be limited to Aggregate Reports. Feedback 436 Reports carry more detailed information and present a greater risk. 438 Due to the inherent Privacy and Security risks associated with PSD 439 DMARC for Organizational Domains in multi-organization PSDs that do 440 not participate in DMARC, any Feedback Reporting related to multi- 441 organizational PSDs MUST be limited to non-existent domains except in 442 cases where the reporter knows that PSO requires use of DMARC (by 443 checking the DMARC PSD Registry). 445 5. Security Considerations 447 This document does not change the Security Considerations of 448 [RFC7489] and [RFC7960]. 450 The risks of the issues identified in [RFC7489], Section 12.3, DNS 451 Security, are amplified by PSD DMARC. In particular, DNS cache 452 poisoning (or Name Chaining), see [RFC3833] for details, consequences 453 are increased because a successful attack would potentially have a 454 much wider scope. 456 The risks of the issues identified in [RFC7489], Section 12.5, 457 External Reporting Addresses, are amplified by PSD DMARC. By design, 458 PSD DMARC causes unrequested reporting of feedback to entities 459 external to the Organizational Domain. This is discussed in more 460 detail in Section 4. 462 6. IANA Considerations 464 This section describes actions requested to be completed by IANA. 466 6.1. Subdomain Policy Tag 468 IANA is requested to add a new tag to DMARC Tag Registry in the 469 Domain-based Message Authentication, Reporting, and Conformance 470 (DMARC) Parameters Registry. The "Status" column is defined in 471 [RFC7489]Section 11.4. 473 The entry is as follows: 475 +----------+-----------+---------+-------------------------------+ 476 | Tag Name | Reference | Status | Description | 477 +----------+-----------+---------+-------------------------------+ 478 | np | this | current | Requested handling policy for | 479 | | document | | non-existent subdomains | 480 +----------+-----------+---------+-------------------------------+ 482 [RFC EDITOR: Please replace "This document" with the RFC number of 483 this document.] 485 7. References 487 7.1. Normative References 489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, 491 DOI 10.17487/RFC2119, March 1997, 492 . 494 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 495 Message Authentication, Reporting, and Conformance 496 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 497 . 499 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 500 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 501 May 2017, . 503 7.2. Informative References 505 [psddmarc.org] 506 multiple, "PSD DMARC Web Site", April 2019, 507 . 509 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 510 Name System (DNS)", RFC 3833, DOI 10.17487/RFC3833, August 511 2004, . 513 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 514 DOI 10.17487/RFC5598, July 2009, 515 . 517 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 518 Morris, J., Hansen, M., and R. Smith, "Privacy 519 Considerations for Internet Protocols", RFC 6973, 520 DOI 10.17487/RFC6973, July 2013, 521 . 523 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 524 Trammell, B., Huitema, C., and D. Borkmann, 525 "Confidentiality in the Face of Pervasive Surveillance: A 526 Threat Model and Problem Statement", RFC 7624, 527 DOI 10.17487/RFC7624, August 2015, 528 . 530 [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen, T., Ed., Zwicky, 531 E., Ed., and K. Andersen, Ed., "Interoperability Issues 532 between Domain-based Message Authentication, Reporting, 533 and Conformance (DMARC) and Indirect Email Flows", 534 RFC 7960, DOI 10.17487/RFC7960, September 2016, 535 . 537 [RFC8020] Bortzmeyer, S. and S. Huque, "NXDOMAIN: There Really Is 538 Nothing Underneath", RFC 8020, DOI 10.17487/RFC8020, 539 November 2016, . 541 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 542 Writing an IANA Considerations Section in RFCs", BCP 26, 543 RFC 8126, DOI 10.17487/RFC8126, June 2017, 544 . 546 7.3. URIs 548 [1] http://publicsuffix.org 550 Appendix A. PSD DMARC Privacy Concern Mitigation Experiment 552 The experiment being performed has three different questions which 553 are looking to be addressed in this document. 555 o Section 3.2 modifies policy discovery to add an additional DNS 556 lookup. To determine if this lookup is useful, PSDs will add 557 additional DMARC records in place, and will analyze the DMARC 558 reports. Success will be determined if a consensus of PSDs that 559 publish DMARC records are able to collect useful data. 561 o Section 3.2 adds the "np" tag for non-existent subdomains (DNS 562 NXDOMAIN). PSOs wishing to test this will add this flag to their 563 DMARC record, and will analyze DMARC reports for deployment. 564 Success will be determined if organizations find explicitly 565 blocking non-existent subdomains domains desirable and provide 566 added value. 568 o Section 4.1 discusses three cases where providing feedback could 569 cause information to leak out of an organization. This experiment 570 will analyze the feedback reports generated for each case to 571 determine if there is information leakage. 573 Appendix B. DMARC PSD Registry Examples 575 To facilitate experimentation around data leakage mitigation, samples 576 of the DNS based and IANA like registries are available at 577 [psddmarc.org]. 579 B.1. DMARC PSD DNS Query Service 581 A sample stand-alone DNS query service is available at 582 [psddmarc.org]. It was developed based on the contents suggested for 583 an IANA registry in an earlier revision of this draft. Usage of the 584 service is described on the web site. 586 B.2. DMARC Public Suffix Domain (PSD) Registry 588 [psddmarc.org] provides an IANA like DMARC Public Suffix Domain (PSD) 589 Registry as a stand-alone DNS query service. It follows the contents 590 and structure described below. There is a Comma Separated Value 591 (CSV) version of the listed PSD domains which is suitable for use in 592 build updates for PSD DMARC capable software. 594 PSDs that are deploying DMARC and are participating in PSD DMARC must 595 register their public suffix domain in this new registry. The 596 requirement has to be documented in a manner that satisfies the terms 597 of Expert Review, per [RFC8126]. The Designated Expert needs to 598 confirm that provided documentation adequately describes PSD policy 599 to require domain owners to use DMARC or that all domain owners are 600 part of a single organization with the PSO. 602 The initial set of entries in this registry is as follows: 604 +-------------+---------------+ 605 | PSD | Status | 606 +-------------+---------------+ 607 | .bank | current | 608 +-------------+---------------+ 609 | .insurance | current | 610 +-------------+---------------+ 611 | .gov.uk | current | 612 +-------------+---------------+ 613 | .mil | current | 614 +-------------+---------------+ 616 B.3. DMARC PSD PSL Extension 618 [psddmarc.org] provides a file formatted like the Public Suffix List 619 (PSL) in order to facilitate identification of PSD DMARC 620 participants. Contents are functionally identical to the IANA like 621 registry, but presented in a different format. 623 When using this approach, the input domain of the extension lookup is 624 supposed to be the output domain of the regular PSL lookup, i.e., the 625 organizational domain. This alternative data approach is potentially 626 useful since DMARC implementations already need to be able to parse 627 the data format, so it should be easier to implement. 629 Appendix C. Implementations 631 There are two known implementations of PSD DMARC available for 632 testing. 634 C.1. Authheaders Module 636 The authheaders Python module and command line tool is available for 637 download or installation from Pypi (Python Packaging Index). 639 It supports both use of the DNS based query service and download of 640 the CSV registry file from [psddmarc.org]. 642 C.2. Zdkimfilter Module 644 The zdkimfilter module is a separately available add-on to Courier- 645 MTA. 647 Mostly used for DKIM signing, it can be configured to also verify, 648 apply DMARC policies, and send aggregate reports. For PSD DMARC it 649 uses the PSL extension list approach, which is available from 650 [psddmarc.org] 652 Acknowledgements 654 Thanks to the following individuals for their contributions (both 655 public and private) to improving this document. Special shout out to 656 Dave Crocker for naming the beast. 658 Kurt Andersen, Seth Blank, Dave Crocker, Heather Diaz, Tim Draegen, 659 Zeke Hendrickson, Andrew Kennedy, John Levine, Dr Ian Levy, Craig 660 Schwartz, Alessandro Vesely, and Tim Wicinski 662 Authors' Addresses 664 Scott Kitterman 665 fTLD Registry Services 666 600 13th Street, NW, Suite 400 667 Washington, DC 20005 668 United States of America 670 Phone: +1 301 325-5475 671 Email: scott@kitterman.com 673 Tim Wicinski (editor) 674 Elkins, WV 26241 675 USA 677 Email: tjw.ietf@gmail.com