Hi Douglas, Thank you for your insightful summary of our paper. I'd like to share some of my opinions.
You mentioned clients lose control of their SPF integrity. It's one of the key problems exactly. Clients host their email services on email providers. They are required to include email providers' SPF records in their SPF records. However, the centralization of SPF deployment magnifies SPF vulnerabilities. Our results show that when the email provider is vulnerable, a single vulnerable SPF record can influence more than 10,000 domains, which actually violates the assumption of SPF that domains can be distinguished by IP addresses. The reliance on IP addresses for sender authentication, a model that might have seemed reasonable 20 years ago, has now proven to be inadequate in today's situation. The centralized deployment of SPF, driven by centralized email services, has only exacerbated the vulnerabilities inherent in this trust model. The cascading effects of a single vulnerable SPF record affecting thousands of domains highlight the fragility of our current email authentication chain. It's also worth noting that a similar centralization phenomenon also exists in the deployment of DKIM (e.g., shared DKIM keys), based on our previous research published in the USENIX Security 2022. https://www.usenix.org/conference/usenixsecurity22/presentation/wang-chuhan Based on the current status of SPF deployment, maybe it's time for us to shift the trust model and explore better approaches to address email authentication issues. Chuhan Wang Tsinghua University > Begin forwarded message: > > From: Douglas Foster <dougfoster.emailstanda...@gmail.com> > Subject: Re: [dmarc-ietf] Break SPF response: DKIM Only > Date: February 29, 2024 at 18:13:53 CST > To: IETF DMARC WG <dmarc@ietf.org> > > SPF trust was promised on the theory that shared infrastructure would prevent > clients from impersonating each other. This document blows up that > assumption. > > It points out that clients have lost control of their SPF integrity. > Neither those clients nor their message recipients have enough data to know > what parts of an SPF policy are unneeded. > > Then it points out that there are attack vectors beyond the imagination of > ordinary mortals. This document is a death knell for unsigned email, and we > need to lead the effort by providing a way for senders to clearly document > that all of their messages are signed. > > Thee are many domains that sign all messages, but there is no way for > evaluators to reliably identify them > > This is not the time for Darwinism ("foolish people get what they deserve"). > The infrastructure companies create the problem, clients choose the vendor, > but unrelated recipients suffer the consequences. The wrong people take the > hit. We need to provide a way to mitigate the harm caused by unjustified > trust in SPF. > > Doug > > On Thu, Feb 29, 2024, 1:29 PM Scott Kitterman <skl...@kitterman.com > <mailto:skl...@kitterman.com>> wrote: > > > On February 29, 2024 6:15:37 PM UTC, Benny Pedersen <m...@junc.eu > <mailto:m...@junc.eu>> wrote: > >Douglas Foster skrev den 2024-02-29 18:48: > >> I am surprised at the lack of feedback about Barry's research link. > >> It is a devastating attack on our ability to trust SPF when shared > >> infrastructure is involved. As a result of that document, I have > >> switched camps and believe that we MUST provide a DKIM-only option for > >> DMARC. > >> > >> The proposed workaround, of using a "?" modifier to force SPF Neutral > >> instead of Pass, seems to lack both awareness and implementation, > >> since it was not even mentioned in the research document as a > >> mitigation. > > > >spf specs have desided to allow +all and unlimited numbers of ips, there is > >no way to stop it unless rfc changes it > > > >even "v=spf1 ip4:0.0.0.0/0 <http://0.0.0.0/0> -all" is fully valid > > > >for maillist is never being dmarc aligned anyway, but direct could be > >aligned, if not a forwarding host does something, with or without srs > > > >maybe rfc wise it could help to have a max ips to get spf pass ? > > > There's no point. As has been discussed for probably 20 years, as soon as > you special case any of these kinds of records, people will move to slightly > more obscure ways to get the same results. > > >From a protocol perspective there's no surprise here. The security > >considerations of RFC 4408 explicitly warned about shared infrastructure > >risks. The challenge is that no one cared. There's no doubt a business > >opportunity here, but I expect no one will pursue it since it doesn't > >require AI. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org <mailto:dmarc@ietf.org> > https://www.ietf.org/mailman/listinfo/dmarc > <https://www.ietf.org/mailman/listinfo/dmarc> > _______________________________________________ > 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
