I gather then that your claim is that RFC 7489 isn't implementable. Is that right?
Scott K On March 22, 2022 11:11:40 AM UTC, Douglas Foster <[email protected]> wrote: >We need an algorithm with enough detail to ensure that it can be >implemented consistently, something closer to the RFC for SPF rather than >RFC 7489. > >For example, it is only when you get into the weeds do you discover that >error handling for the primary walk needs to be different than error >handling for the secondary walk, and that this has security implications. > A policy error on the secondary walk MUST be ignored, rather than >triggering PERMERROR. Otherwise an attacker could create a domain with an >invalid DMARC policy, then sign an impersonating message with that domain, >causing the evaluator to conclude PERMERROR instead of REJECT, defeating >the domain owner policy. > >We need to have though through the implementation issues with as much care >as will be needed by developers. This is no small feat. I have already >thought of a few refinements since last night. We probably cannot succeed >without a reference configuration. > >I don't have any problem with the tree walks as a replacement for the PSL. > But I don't think we are close to a usable document because it is simply >too vague. > >Doug > > >On Tue, Mar 22, 2022 at 12:16 AM Scott Kitterman <[email protected]> >wrote: > >> Doug, >> >> I think you are mistaken. The Organizational Domain is what is used to >> test alignment. If you have suggested changes from what's in DMARCbis06, I >> think it would be easier if you made specific recommended changes. >> >> Also, the level of detail in the current draft is very similar to what is >> in RFC 7489. If you think we need a more detailed exposition than there is >> in the existing DMARC spec, please explain what current issues you are >> seeing that you are trying to solve. >> >> I find it very difficult to relate what is in your email to the text in >> the draft. >> >> Scott K >> >> On March 22, 2022 3:03:59 AM UTC, Douglas Foster < >> [email protected]> wrote: >> >We have significant functional differences between the two tree walks, >> >which are lost or ignored in the current prose. This lack of precision >> >has also allowed us to overlook error handling, which is different between >> >the two types of tree walk. >> > >> > >> >I have provided a rough cut of the primary tree walk, using an outline >> >approach rather than prose. For the secondary tree walk, I only have >> >summary comments about how it differs from the primary tree walk. I could >> >beef up both sections after feedback >> > >> >Doug >> > >> >There are potentially two types of tree walks, both of which can be >> avoided >> >under specific circumstances. >> > >> >- The primary tree walk is used to find the RFC5322.From address >> >organizational domain and associated default policy, and is performed >> >once. >> > >> >- The secondary tree walk is used to test each verified domain for >> >alignment with the RFC5322.From domain. >> > >> > >> > >> >1) RFC5322.From tree walk to Organizational Domain >> > >> > >> > >> >Exact-match check >> > >> >------------------------- >> > >> >- (optionally) verify that the lowest segment is a valid label (doesn't >> >start with an underscore, 64 or fewer characters long. If format rules >> are >> >violated, return an error. >> > >> >- check for TXT records at _dmarc.<domain name> >> > >> >- if no DMARCv1 records are found, report no-data-found and exit. >> Proceed >> >to the organization domain and default policy search. >> > >> >- if two records are found, or if a single record does not parse >> correctly, >> >return an error. >> > >> >- if one usable record is found, check for a <role> indicator, and proceed >> >as follows: >> > >> > If a <not-for-mail> indicator is detected, return a DMARC Fail >> result. >> > >> > If both alignment policies are strict, the organization domain and >> >policy are not needed, so the primary tree walk is omitted. Otherwise, >> the >> >tree walk is invoked to determine the organizational domain and default >> >policy >> > >> > >> > >> >If the tree walk is to be used, check to see if the From domain is more >> >than <Max=5> segments. If so, shorten the domain to <Max=5> segments. >> >Otherwise, remove one segment and check the resulting domain name for a >> >DMARC policy. Then evaluate the shortened domain name: >> > >> > >> > >> >- (optionally) verify that the first segment of the domain name is a >> >valid label (doesn't start with an underscore, 64 or fewer characters >> >long. If format rules are violated, return an error. >> > >> >- check for TXT records at _dmarc.<domain name> >> > >> >- if no DMARCv1 records are found, report no-data-found and exit the step >> >so the search can continue. >> > >> >- if two records are found, or if a single record does not parse >> correctly, >> >return an error. >> > >> >- if one usable record is found, check for a <role> indicator, and proceed >> >as follows: >> > >> > If a <non-boundary role> indicator is present, return no-data-found >> >and exit the step so the search can continue. >> > >> > If a <psd role> indicator is present, return the cached domain and >> >policy, ending the search. >> > >> > If a <top-of-organization role> indicator is present, return the >> >current domain and policy, ending the search. >> > >> > If no indicator is found, cache the domain name and policy as a >> >possible organizational domain. Exit the step so the search can continue. >> > >> > >> > >> >If a step exits with a confirmed organizational domain and default policy, >> >the search is complete. >> > >> >If a step exits with no-data-found, and the domain name has at least 2 >> >segments, then remove the first segment and repeat the domain evaluation. >> > >> >If a step exits with no-data-found, and the domain name is only 1 segment, >> >then the search terminates. >> > >> > If a cached organization domain and default policy are available, >> these >> >are the organizational domain and default policy. >> > >> > If the cache is empty, no organizational domain is found. >> > >> > If an exact-match policy was previously detected, so that the >> >tree walk was only needed for relaxed alignment, then the match rule >> >reverts to strict. >> > >> > If an exact-match policy was not detected, the domain does not >> >participate in DMARC. >> > >> > >> > >> > >> > >> >2) Secondary Tree walk to test for alignment >> > >> > >> > >> >This has some notable differences from the Primary Tree Walk. >> > >> >- The search only returns an “Aligned” or “Unaligned”. The >> >values of the organization domain name and default policy will be known if >> >the names are aligned, and unimportant if the names are not aligned. >> > >> >- Only one alignment result is needed, so domain evaluation >> ceases >> >as soon as an aligned result is obtained. >> > >> >- If a DMARC policy error is detected during evaluation, the >> >domain being evaluated is discarded as not aligned, but the evaluation >> >proceeds. >> > >> >- The common substring should be determined. If the common >> >substring is shorter than the organizational domain, the domains are not >> >aligned, and the tree walk is not necessary. Otherwise, the tree walk is >> >performed, but it terminates when the common substring is reached, rather >> >than when the domain string is exhausted. >> > >> >- If an organization boundary is detected during the tree walk, >> >the domain being evaluated is discarded as not aligned. >> > >> >- If no organization boundaries are identified during the tree >> >walk, the names are aligned. >> > >> >If the domain is discarded as not aligned, the alignment search proceeds >> to >> >the next DKIM-verified or SPF-verified domain name. >> > >> >If the set of verified domain names contains any duplicates, only one >> >evaluation needs to be performed and the duplicates can be ignored. >> > >> >There are significant benefits expected from prioritizing the order in >> >which verified domain names are tested. Recommended sequence: >> > >> >- Exact-match domains >> > >> >- Parent domains. Only the longest match needs to be evaluated. >> > >> >- Child domains. Only the shortest match needs to be evaluated. >> > >> >- Sibling domains. Process in order from longest common >> >substring to shortest common substring. >> >> _______________________________________________ >> dmarc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmarc >> _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
