Neil, to your question about mitigating false SPF PASS: There are three possible mitigations by senders:
- Drop the SPF policy so that messages evaluate to SPF None. A few domains do this. - Change the SPF Policy to return SPF Neutral for cloud services, as currently proposed. - Provide a DMARC option for "DKIM only", which has been proposed and rejected. All of these options depend on a sender being willing to give up SPF Pass. In my own reporting data, I see some occurrences of DNS Timeout on DKIM checks, an event over which I have no control, so I don't know that even I want to give up SPF Pass. I don't think we can expect senders to choose any of the options, even if all three were to be made available. The necessary response is for evaluators to identify those domains that reliably carry DKIM signatures, and to configure those domains for "DKIM Only" processing at reception. Failures should be routed to quarantine for further investigation. Even in my relatively modest data set, I have about 2000 domains that are candidates for this treatment. By comparison, I have only about 20 domains that use DKIM signatures with SPF None to avoid the problem. Doug Foster On Tue, Mar 12, 2024 at 3:32 PM Neil Anuskiewicz <n...@marmot-tech.com> wrote: > > > On Mar 4, 2024, at 11:07 PM, Chuhan Wang <wc...@mails.tsinghua.edu.cn> > wrote: > > > 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 > > > Sir, I was wondering if you could provide a short, concise proposal to > mitigate this problem? Perhaps how you might introduce a student to a new > concept. >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
