If we start from Dave Crocker's assumption that we will have at least two algorithms, defined somewhere, then I find Michael Hammer's argument compelling: We should encourage migration to an environment that requires a parent-child relationship for relaxed alignment.
The parent-child requirement virtually eliminates the risk of false positives, based on two assumptions: (1) that upward attacks are unlikely because registrants have strong incentives to not attempt malicious impersonation of the entity that registered them, whether the registrar is a true PSD or a lease grantor, as this would likely lead to de-registration, (2) that downward attacks are unlikely because PSDs do not send mail and lease grantors are not likely to attack their lease-holders, as this undermines the trust needed by their business model. Additionally, the parent-child requirement seems essential to the success of a simplified non-PSL algorithm. I also suggest that removing siblings from relaxed alignment will not cause many objections. I have never seen a message that depends on sibling authentication, and no one else has submitted any data suggesting that it is commonly used. Consequently, I see us moving to three documented algorithms: - the original RFC 7489 algorithm based on PSL with siblings allowed, - a modified algorithm based on PSL but with parent-child required, and - a simplified algorithm that does not use the PSL and has parent-child required. To that end, it seems desirable to give domain owners a DNS flag to indicate that they have embraced this new approach and do not want sibling relationships to be used for relaxed authentication. Similarly, the reporting specification should be tweaked to allow evaluators to report which of these three algorithms were used for DMARC evaluation. If domain owners notice that many evaluators do not accept sibling authentication, they will necessarily take measures to eliminate sibling-dependent authentication from their mail stream. Similarly, when evaluators see that some domain owners explicitly reject sibling authentication, and others do not use it, they will become willing to stop using sibling relationships in their evaluation. Doug Foster On Tue, Jan 25, 2022 at 1:29 PM Dotzero <[email protected]> wrote: > > > On Tue, Jan 25, 2022 at 12:40 PM John Levine <[email protected]> wrote: > >> It appears that Scott Kitterman <[email protected]> said: >> >My impression is that the group is generally okay with PSD=y. I prefer >> it over your suggestion. My strongest preference is that we pick >> something, stick with it, and move on. >> >> I think I see where Ale's confusion is coming from. If we switch to a >> tree walk, we will have an algorithm rather than a heuristic, so >> anyone looking at the same domains and the same set of DMARC records >> will get the same result. It also occurs to me that in the absence of >> a PSL-like thing, the idea of an organizational domain is no longer >> useful. >> >> There's two questions to answer: what is the policy for a domain, and are >> two domains in relaxed alignment. >> >> The answer to the first one is straightforward: start at the domain, walk >> up the tree, and the first DMARC record >> you find is the policy record. If you don't find one, there's no policy. >> >> The answer to the second has two cases: >> >> If one domain is a subdomain of the other, and there is no policy record >> (or maybe no PSD policy record) between >> them, they're in relaxed alignment. >> > > I have no problem with this. Those of us who originally created DMARC > considered this the use case for relaxed. > >> >> If they are cousin domains, walk up the tree from each until you find a >> policy record. If you find the same policy >> record and it's not a PSD and it allows relaxed alignment, they're in >> relaxed alignment. If you find different >> records, or only one record, or no records, they aren't. >> >> I think a better term is sibling domains. The phrase "cousin domains" has > typically been used for look alike domains rather than the subdomain issue. > > >> As a special case, a domain with a PSD record is never aligned with >> anything but itself. >> (I realize .bank will never send mail, but us.com might.) >> >> The cousin domain rule doesn't exactly reproduce what the PSL is intended >> to do, but I think it covers >> the useful cases and is unlikely to allow accidental cousin alignment >> which Mike keeps reminding us about. >> > > It actually does allow malicious, not accidental, alignment. I'm done > reminding. This allows an attack vector which can be useful for BEC > attacks, hostile governments targeting NGOs, journalists, etc. and other > targeted attacks. It is not a particularly useful attack vector for large > scale opportunistic abuse such as spam or widespread attempts to spread > malware. The group will address it or not as it chooses. I've been working > on developing real world attack example (defanged) and have just started > discussing the issue with various (red team) security folks I know and > reaching out to some .gov folks I know. bSidesLV may be held this year and > I may present on this there or at other venues. If allowing alignment and a > pass based on a sibling domain is allowed in DMARC then the best defense is > for people to understand that there are potential real world risks in > relying on a DMARC pass in relaxed mode. > > Michael Hammer > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
