idnits 2.17.1 draft-levine-dmarcwalk-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 document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (20 November 2020) is 1246 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Levine 3 Internet-Draft Standcore LLC 4 Intended status: Standards Track 20 November 2020 5 Expires: 24 May 2021 7 DMARC Fallback Domains 8 draft-levine-dmarcwalk-00 10 Abstract 12 This document specifies a new tree walk algorithm to find a DMARC 13 Fallback Domain. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on 24 May 2021. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Simplified BSD License text 43 as described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Fallback Domain . . . . . . . . . . . . . . . . . . . . . . . 2 50 2.1. Default Fallback Domain . . . . . . . . . . . . . . . . . 3 51 3. Legacy Organizational Domain . . . . . . . . . . . . . . . . 3 52 4. Differences between Fallback and Legacy Organizational 53 Domains . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 5. Informative References . . . . . . . . . . . . . . . . . . . 4 55 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 57 1. Introduction 59 DMARC allows domains to publish DNS records describing their 60 preference for recipients of mail purporting to be them. The policy 61 record is found in two possible places: the domain in the 62 RFC5322.From[RFC5322] header, or failing that, an ancestor of that 63 domain. In the previous version of DMARC the second domain is called 64 the Organizational Domain, as described below in Section 3. This 65 document describes a new algorithm to find a Fallback Domain. 67 If a DMARC check uses a Fallback Domain, that domain is used in the 68 same way that a Legacy Organizational Domain is used in [RFC7489]. 70 2. Fallback Domain 72 The Fallback Domain is found using a tree walk. 74 1. Call the RFC5322.From domain the Current domain. 76 2. Delete the leftmost (low-order) label from the Current domain. 77 If there are no labels left, stop. Otherwise call the new 78 shorter domain the new Current domain. 80 3. Prepend _dmarc. to the Current domain and check for a valid DMARC 81 policy record at that name in the DNS. If one exists, stop. 83 4. Otherwise, return to step 2 and repeat until four potential 84 Fallback Domain names have been checked. 86 For example, if the RFC5322.From domain is sales.examp1e.com, the 87 sequence of names to check would be: 89 _dmarc.sales.examp1e.com 90 _dmarc.examp1e.com 91 _dmarc.com 92 If the RFC5322.From domain is sales.east.widgets.bigcorp.com.example, 93 the sequence of names would be: 95 _dmarc.sales.east.widgets.bigcorp.com.example 96 _dmarc.east.widgets.bigcorp.com.example 97 _dmarc.widgets.bigcorp.com.example 98 _dmarc.widgets.bigcorp.com.example 99 _dmarc.bigcorp.com.example 101 2.1. Default Fallback Domain 103 If the process in the previous section terminates after checking the 104 RFC5322.From name and four potential Fallbak Domain names without 105 finding a valid DMARC policy record, synthesize a policy record for 106 the RFC5322.From domain containing: 108 v=DMARC1; p=reject; 110 The four label limit is intended to mitigate DNS attacks on mail 111 systems using RFC5322.From addresses with very long labels that would 112 otherwise cause very long tree walks. This avoids the possibility of 113 maliciously avoiding DMARC checks by using very long names. Note 114 that if the RFC5322.From name does not exist in the DNS, DMARC checks 115 will always fail since there can be no SPF or DKIM records to 116 validate the name. 118 3. Legacy Organizational Domain 120 The legacy Organizational Domain is determined using the following 121 algorithm: 123 1. Acquire a "public suffix" list, i.e., a list of DNS domain names 124 reserved for registrations. Some country Top-Level Domains 125 (TLDs) make specific registration requirements, e.g., the United 126 Kingdom places company registrations under ".co.uk"; other TLDs 127 such as ".com" appear in the IANA registry of top-level DNS 128 domains. A public suffix list is the union of all of these. 130 2. Break the subject DNS domain name into a set of "n" ordered 131 labels. Number these labels from right to left; e.g., for 132 "example.com", "com" would be label 1 and "example" would be 133 label 2. 135 3. Search the public suffix list for the name that matches the 136 largest number of labels found in the subject DNS domain. Let 137 that number be "x". 139 4. Construct a new DNS domain name using the name that matched from 140 the public suffix list and prefixing to it the "x+1"th label from 141 the subject domain. This new name is the Organizational Domain. 143 Thus, since "com" is an IANA-registered TLD, a subject domain of 144 "a.b.c.d.example.com" would have an Organizational Domain of 145 "example.com". 147 4. Differences between Fallback and Legacy Organizational Domains 149 Since the methods of finding the Fallback and Legacy Organization 150 Domains are different, they will not always find the same policy 151 record. 153 If there is a policy record at the Legacy Organizational domain, and 154 not at any other intermediate name above the RFC5322.From domain, the 155 two methods will yield the same result, so long as there are no more 156 than four labels betwen the Legacy Organizational Domain and the 157 Fallback Domain. 159 If there are policy records at intermediate names, those records will 160 take precedence over the Legacy Organizational domain. This allows 161 organizations to delegate DMARC policy authority on more finely than 162 the Legacy Organizational domain does. 164 If there is no policy record at the the Legacy Organizational domain, 165 but there is one at a name higher in the name tree, the result is 166 similar to that in I-D.draft-ietf-dmarc-psd-08. 168 The use of the Default Fallback domain means that any system that 169 sends mail using a RFC5322.From domain more than five labels long 170 must publish a DMARC policy record or its mail will all fail DMARC 171 checks. In practice, we have rarely seen valid mail domains that 172 long; but if it's an issue, changing the limit from 5 labels to 7 or 173 10 would still deter DNS attacks. 175 The Fallback Domain method is deterministic and will always find the 176 same record, while the Legacy Organizational method depends on the 177 contents of the public suffix list that it uses. 179 5. Informative References 181 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 182 DOI 10.17487/RFC5322, October 2008, 183 . 185 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 186 Message Authentication, Reporting, and Conformance 187 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 188 . 190 Author's Address 192 John Levine 193 Standcore LLC 195 Email: standards@standcore.com