Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

[Wei Chuang <[e-mail]>]

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=
[e-mail]> wrote:

> * Alessandro Vesely <[e-mail]>:
> > 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, [phone] <+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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>