Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up
> On Jan 25, 2022, at 10:35 AM, John R Levine wrote: > > Do we have any stats on how often real mail depends on sibling alignment? If > nobody actually uses it, the spec would be simpler if we could take it out. Stats are tricky, but here are some senders using sibling alignment like From domain: samedaycity.FedEx.com DKIM domain: freight.FedEx.com SPF domain: nds.FedEx.com Most of these don’t do it for all mail, but account and billing related mail or customer support mail are particularly likely to use it FedEx, obviously Uber Intuit NextDoor outside the US Taco Bell McGill university Lots of healthcare billing using the Cedar platform Atlassian Alignable.com which tickles my sense of irony Cmdlr.com which sends mail for a variety of car dealerships These are cherry-picked from a few minutes of incoming mail. So in practice, turning it off would cause significant disruption. Elizabeth > > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up
On Tue 25/Jan/2022 20:39:11 +0100 Murray S. Kucherawy wrote: On Tue, Jan 25, 2022 at 11:26 AM John R Levine wrote: On Tue, 25 Jan 2022, Murray S. Kucherawy wrote: 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. Aren't we basically trying to identify the same thing, just in a different (and more robust) way? >> Yes, but that leads to the question of whether the org domain is useful on its own or it's just a way to figure out alignment. I think it's the latter, dunno what other people think. It's an interesting thought exercise at least. We should be sure to give a decent treatment to this in the "differences since RFC 7489" part of the document. The concept of Organizational Domain is a key concept, as it is easy to understand, based on intuitive set theory ideas. With respect to earlier SPF experience, which required tagging each and every domain name in an organization, it is an invaluable progress. Replacing it with a difficult graph-theoretical argument is going to make the notion of alignment much more difficult to explain. The mere fact that adding a DMARC record can change alignment properties turns such a simple operation into something that requires an extensive analysis before it can be carried out. If we drop Organizational Domain we're probably better off dropping alignment as well. We're worsening DMARC in that case. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up
On Tue, Jan 25, 2022 at 11:26 AM John R Levine wrote: > On Tue, 25 Jan 2022, Murray S. Kucherawy wrote: > >> 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. > > > > Aren't we basically trying to identify the same thing, just in a > different > > (and more robust) way? > > Yes, but that leads to the question of whether the org domain is useful on > its own or it's just a way to figure out alignment. I think it's the > latter, dunno what other people think. > It's an interesting thought exercise at least. We should be sure to give a decent treatment to this in the "differences since RFC 7489" part of the document. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up
On Tue, 25 Jan 2022, Murray S. Kucherawy wrote: 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. Aren't we basically trying to identify the same thing, just in a different (and more robust) way? Yes, but that leads to the question of whether the org domain is useful on its own or it's just a way to figure out alignment. I think it's the latter, dunno what other people think. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up
On Tue, Jan 25, 2022 at 9:40 AM John Levine wrote: > It appears that Scott Kitterman 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. > Aren't we basically trying to identify the same thing, just in a different (and more robust) way? I'd be careful about saying "no longer useful"; doing so implies a much bigger change than we might be aiming to "sell" here. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up
On Tue, 25 Jan 2022, Dotzero wrote: 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. Agreed, sibling is better, although of course they could be great-aunts, too. 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. I don't have strong opinions about whether to continue to allow great-aunt alignment other than to note this is such a well known problem that it is exactly the problem the PSL was invented to address, and we can argue about how well the PSL and other widely available mitigation techniques work and how reasonable it is to expect people to use them. Do we have any stats on how often real mail depends on sibling alignment? If nobody actually uses it, the spec would be simpler if we could take it out. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up
On Tue, Jan 25, 2022 at 12:40 PM John Levine wrote: > It appears that Scott Kitterman 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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up
On January 25, 2022 5:40:09 PM UTC, John Levine wrote: >It appears that Scott Kitterman 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. > >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. > >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. > >Suggestions and tweaks (with an explanation of what problem they fix) welcome. I think this is generally correct. Can be used for relaxed alignment was always the important thing for organizational domain anyway. I don't know that I'd bother to create the term now, but we already have it and people sort of know what it means, so I think we might as well keep it. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up
It appears that Scott Kitterman 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. 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. 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. Suggestions and tweaks (with an explanation of what problem they fix) welcome. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
