For the shared provider SPF upgrade example, I think Scott's previously mentioned method of using SPF '?' qualifier on the relevant shared mechanism mitigates the upgrade problem, and ensures only DKIM can provide passing authentication.
Thinking back earlier this year to the well-publicized SPF upgrade vulnerability of a certain vendor, many affected senders mitigated it until fixed by the vendor by utilizing the aforementioned neutral ? qualifier method to great effect. Do we really need this when existing protocol methods of mitigating SPF upgrades already exist? This is basically like painting a potato red, and calling it a tomato. It still tastes like a potato. -Mark Alley On Sat, Oct 28, 2023, 3:04 PM Emanuel Schorsch <emschorsch= 40google....@dmarc.ietf.org> wrote: > As to why, I don't think there's a valid use case and the proponents for >> this haven't really thought it through. As an example, someone (I don't >> recall who) cited the issue of domain owners that publish SPF, but can't be >> bothered to set up DKIM. The implication is that this minimum effort >> domain owner will read DMARCbis when it comes out and decide to update >> their records as a result with the new tag. I don't think that's very >> realistic. >> >> So who would use this tag then? >> >> It would have to be a domain owner which publishes an SPF record that >> enables spoofing their domain, understands SPF and DMARC well enough to >> know that is a concern for DMARC and yet simultaneously doesn't know how to >> fix their SPF record and does know about this new tag. >> >> I don't think that person exists. At best this new tag is some kind of >> security theater. >> > > Thanks for that clarification! I think I can clear up what the specific > use case is. It's to deal with SPF Upgrade. Assume we have a domain, ` > business.com`, that has properly set up SPF and DKIM and uses a shared > provider and so includes the relevant provider IPs in their SPF record. > They have a DMARC p=reject policy. But, unfortunately, the shared provider > they use is vulnerable to SPF upgrade and so there have been successful > upgrades allowing a spammer / phisher to achieve a `business.com` SPF > pass. Notably, this does not allow the spammer to achieve a `business.com` > DKIM pass. Today, this will be a DMARC pass (because of the SPF), and it is > not always so easy for downstream receivers to know there has been an > upgrade. > > Take the above example, and imagine we've added an `auth=dkim` tag option. > `business.com` then adds it to their DMARC record to protect their > domain. Now, when a receiver gets the upgraded message they see it is a > DMARC fail and can reject the message. This protects the `business.com` > domain from impersonation in a way that is not possible today without ` > business.com` either removing SPF or leaving their shared provider (the > only ways to "fix their SPF record"), both a much larger change. Does that > make more sense as a legitimate use case? > _______________________________________________ > 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
