Unfortunately, the PSL is not an adequate tool for validating the Tree Walk algorithm. You disparaged that idea when I proposed it earlier, and you were right.
The expected PSL error is domain fragmentation, because Cross-Site-Scripting scope boundaries are likely to be narrower than email domain boundaries. The expected Tree Walk error is domain consolidation, because missing information will cause the walk to continue upward. When the two algorithm results are compared, we know nothing about which algorithm is mistaken. (Maybe both algorithms are incurring their respective error types are occurring at the same time!) We have a fundamental weakness when a trust-verification algorithm like DMARC is highly dependent on unverifiable data about organizational boundaries. The PSL algorithm has this problem, which is why we are considering a replacement, but at least its mistakes are not considered malicious. Additionally, a domain owner can manage the consequences of domain fragmentation by adding more DMARC policies and adjusting DKIM signature domains. For the Tree Walk Algorithm, mistakes are likely to be malicious, and the malicious domain owner has no incentive to fix the problem. Observing that malicious use will only be possible on a few domains is not the same as solving the problem. I have proposed a solution to this problem, which replaces the awkward and "intentionally confusing" psd=n token with the more useful OrgsBelow=<integer> token. The OrgsBelow token both indicates an organizational domain and defines the subtree to which it applies. Consequently, if fixes the known vulnerability in the Tree Walk algorithm. The real question is why there is resistance to solving the problem correctly. On Sun, May 1, 2022 at 7:59 PM Scott Kitterman <[email protected]> wrote: > > > On May 1, 2022 11:25:02 PM UTC, Neil Anuskiewicz <neil= > [email protected]> wrote: > > On Apr 24, 2022, at 8:57 PM, Scott Kitterman <[email protected]> > wrote: > >> > >> For cases where strict alignment is not appropriate, this issue can be > >> mitigated by periodically checking the DMARC records, if any, of PSDs > >above > >> the organization's domains in the DNS tree and (for legacy [RFC 7489] > >checking > >> that appropriate PSL entries remain present). If a PSD domain > publishes a > >> DMARC record without the appropriate psd=y tag, organizational domain > >owners > >> can add psd=n to their organizational domain's DMARC record so that the > >PSD > >> record will not be incorrectly evaluated to be the organizational > domain. > > > >Though the risk’s low, “periodically checking the DMARC records, if any” > >isn’t particularly reassuring. It’s like saying periodically give your > >pilot a breathalyzer. :-) > > I agree, although in this case it can be automated. Similarly, > periodically checking the PSL under the current scheme would be a good idea > and not hard to do. > > Scott K > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
