As DMARC is intended to protect the From header from spoofing, we support moving DMARCbis authentication to DKIM-only due to the recent demonstration of such spoofing that was enabled by an SPF upgrade attack as described in [1]. That paper cites the vulnerability of Federal government, financial, commercial and other senders to phishing attacks. (Anecdotally we spot checked some 10 financial companies for a different reason, and found 3 of them were similarly vulnerable). So it's really important to mitigate this vulnerability from DMARCbis. That said, we really want to emphasize that SPF is still very useful and important for email authentication as it is a rather important part of a portfolio of authentication signals for Gmail, and has a complementary role to DKIM in our system. In fact, our forwarders guidance calls for supporting DKIM and SPF [2], and this is really true for any traffic (forwarded or from some originator) to Gmail.
Our email authentication numbers roughly look similar to other large senders. Our DMARC percentages are as follows (queried over a week), and qualified as accepted messages. DmarcPolicy count REJECT 45.60% absent 22.73% NONE 18.78% QUARANTINE 12.89% 100.00% We then look at DKIM and SPF authentication rates (and independent of DMARC). The following numbers come from deeper in the delivery pipeline after being accepted and evaluating DMARC policy. We see that SPF provides coverage for DKIM authentication gaps. The following table shows the percentage of messages with SPF pass (true/false) and RFC8601 <https://datatracker.ietf.org/doc/html/rfc8601#section-2.7.1> DKIM authentication-results. Of this traffic, DKIM is not passing for 5.56% and there's SPF coverage for 4.78%. A large cause for this is messages that were not DKIM signed but could be validated with SPF at 3.91%. ConcatSpfPassDkimAuthResults SUM of TRUE,PASS 92.58% TRUE,NEUTRAL 3.91% FALSE,PASS 1.85% FALSE,NEUTRAL 0.72% TRUE,FAIL 0.69% TRUE,TEMPERROR 0.17% FALSE,FAIL 0.05% FALSE,TEMPERROR 0.02% TRUE,POLICY 0.00% FALSE,POLICY 0.00% Grand Total 100.00% When we break up this traffic by distinct domain counts, the view is different. There notably appears to be many more senders for DKIM than SPF which is surprising (DKIM: 73.26%, SPF 35.34%). We haven't analyzed this further but there may be many more DKIM capable senders than previously thought. Unfortunately one hypothesis is that many of these senders are spammers that are able to use authentication more proactively than regular senders. Even so, the DKIM not passing rate is 26.74%, and SPF can provide coverage for 17.41%. ConcatSpfPassDkimAuthResults SUM of FALSE,PASS 55.33% TRUE,PASS 17.93% TRUE,NEUTRAL 15.30% FALSE,NEUTRAL 7.58% TRUE,FAIL 1.09% TRUE,TEMPERROR 0.98% FALSE,FAIL 0.97% FALSE,TEMPERROR 0.76% TRUE,POLICY 0.04% FALSE,POLICY 0.02% Grand Total 100.00% Because from these numbers, we can see that SPF does provide significant coverage when DKIM is not present, so we need to find a bridging process if we are to move to DKIM-only for DMARCbis. Our proposal would be for DMARCbis to maintain the default for SPF and DKIM support, and to support senders that want to drop SPF as one of their DMARC authentication methods to avoid the SPF upgrade vulnerability. We could have a DMARC policy tag for authentication e.g. "auth=" that describes the permitted authentication methods the sender supports and receiver MUST use for validation. DKIM or SPF are represented as tags "dkim" and "spf", and if multiple tags are present then they are comma separated and any one passing is considered passing authentication. Also at least one authentication method MUST be present. Other authentication methods could be added in the future as it is our hope that there will be some other authentication method to improve upon and someday replace SPF. overall. If "auth=" is missing, then DMARC falls back to supporting SPF and DKIM. The proposed deployment process would be that senders at higher risk from >From header spoofing will invest in deploying DKIM and will declare authentication as DKIM-only. SMB senders can still bootstrap their DMARC deployment by using SPF but hopefully will lower their risk by avoiding the SPF include policy patterns described in [1]. In order to bring together these new configurations over the long term, DMARCbis might want to define a "DMARC2" configuration that symbolically defines the end authentication goal e.g. it might be the "retirement" of SPF. -Wei on behalf of the Gmail security team [1] https://www.sysnet.ucsd.edu/~voelker/pubs/forwarding-eurosp23.pdf [2] https://support.google.com/mail/answer/175365?sjid=1196932423118655843-NA On Mon, Jun 19, 2023 at 11:42 AM Patrick Ben Koetter <p= 40sys4...@dmarc.ietf.org> wrote: > * Alessandro Vesely <ves...@tana.it>: > > On Thu 15/Jun/2023 23:25:44 +0200 Tero Kivinen wrote: > > > > > > I rerun the statistics and yes, there is 0.84% cases where dkim > > > failed, but spf returned either pass, softfail or neutral. > > > > Many thanks. That figure seems to be more or less in agreement with what > > others here have obtained on smaller samples. However small, it may > confer > > to SPF the role of a stabilizer in DMARC mail flows. > > The number of IP addresses in SPF-Records published by VLMPs foils the > idea of > "a controlled and limited number of host allowed to send on behalf of a > senderdomain". Given the (internal routing) challenges you face when you > try > to publish a limited, dedicated IP range per tenant only, I do not see the > current problem we have with SPF, when it comes to use SPF as identity > anchor for email authentication, go away in the future. To me SPF > destabilizes > email authentication. It should not be used in future version of DMARC > anymore. > > But why is it so many hang to SPF? > > My personal experience as a consultant is many domain owners prefer SPF > over > DKIM because SPF is easier to implement. They don't care about the one > being > the superior identity anchor to the other. They want to send. They want > deliverability. And they want to get it done as soon as possible at the > least > investment. Business. Efficency. > > As long as I can think of generating and handling DKIM keys has been a > pain. > There's SHA1 and SHA256, then RSA and ED25519, then there's quite a > variety of > flags to publish (test mode, email usage only, ...) and even if you > managed to > get all of that right you are likey to fail when it comes to publish the > DNS > TXT record. It's overly long requires multiline quoting etc. pp. and I've > seen > experienced DNS operators fail repeatedly to get it right at first attempt. > > Many get publishing DKIM keys wrong, but that doesn't hurt them as long as > SPF > passes during DMARC authentication. They can send. They get deliverability. > Why bother with DKIM problems? > > If we drop SPF in DMARCv2 SPF in all its dominance will suddenly be absent > and > DKIM with all its implementational problems will suddenly be fully exposed. > And people will suddenly be forced to implement DKIM and suffer from all > the > pain I've described above. I do expect them to be not amused - to put it > friendly. > > I suggest that we do not only drop SPF, but also come up with better ways > (simplification, tools, exchange formats) to implement DKIM in order to > allow > for a smooth transition. > > p@rick > > > -- > [*] sys4 AG > > https://sys4.de, +49 (89) 30 90 46 64 <+49%2089%2030904664> > Schleißheimer Straße 26/MG,80333 München > > Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 > Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief > Aufsichtsratsvorsitzender: Florian Kirstein > > _______________________________________________ > 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