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

[Scott Kitterman <[e-mail]>]

On Friday, June 9, 2023 4:33:54 AM EDT Barry Leiba wrote:
> I think, Scott, that you and I have a fundamental disagreement that's
> not resolvable, and I won't just repeat what I've already said.  But a
> couple of the things you said are ones I can't make sense of, so I'll
> 
> talk about those:
> > Software engineering isn't a perfect science.  In general, a more
> > complex protocol will suffer more defects.  If you want to design
> > things that only work when software is perfect, I'm not interested.
> 
> It seems that you're saying you're "not interested" in any protocol
> that won't work if there's a software bug, and that makes no sense to
> me.  Crypto is hard to get right and there are often bugs; TLS won't
> work if you don't get the crypto right: does that mean you're not
> interested in TLS?  Or VPNs (IPsec)?  Are you not interested in TCP
> because it will fail if there's a bug in the network stack?  For that
> matter, a router with a bug in its MPLS implementation won't work:
> should we not use MPLS?  And, well, if there's a bug in your
> SPF-record parser, SPF won't work either, n'est-ce pas?
> 
> Of course, the level of failure in any of this depends upon just what
> the bug is.

Thanks for pushing back on this.  It was poorly worded.  Let me try again, see 
below.

> > One could make the opposite argument too, and I think it would be
> > equally valid:
> > 
> > The only value DKIM brings for DMARC is for indirect mail flows.  For
> > any direct connections, SPF is sufficient.  All the proposed DKIM
> > changes to solve the DKIM replay problem are likely to break indirect
> > mail flows anyway, so there's no longer a point to keep DKIM.  It's
> > much more complicated and it looks like the benefit of it is going
> > away, let's just simplify the protocol and get rid of it.
> 
> This also makes no sense, as it completely misrepresents the situation
> I'm raising.  It *doesn't* work both ways, because DKIM works in all
> situations that SPF does, but it *also* works in some situations where
> SPF fails.  The opposite is not true.  DKIM adds value beyond what SPF
> does.  SPF does not add value, ever.
> 
> You and Mike seem to be holding on to SPF because you want to, with
> some vague "I've seen network errors and software errors" statements
> but without real arguments.  The only real argument I've seen is
> Seth's about broader deployment of SPF without DKIM.  I've already
> said why I think that's not a reason we should keep SPF, but at least
> that is a reason I can make sense of.

It's not a case of I've seen a few failures, it's consistent (all I can say 
for certain is that it was as I no longer have access to this data).  It was 
consistent across time and providers.  At scale, DKIM would always have a 
fraction of a percent failure rate, while SPF would not (for direct 
connections - I have no disagreement with your statement that SPF doesn't help 
with indirect mail flows).  This probably exculpates DNS as a source of the 
DKIM failures, since I think it's not likely that SPF records could be 
retrieved when DKIM key records could not, but I don't know for sure.

The leads to a situation where the DMARC pass rate for direct connections 
would vary depending on if SPF was included:

DKIM only: ~99.5%
DKIM + SPF: ~100%
SPF only: ~100%

You may not think that last half of a percent is important (my recollection is 
that it varied a bit between 0.2% and 0.8%), but I think it exists and is 
important.

The point I was attempting (badly) to make is that I have seen data that's 
contrary to your claim that there is no case where SPF will enable a DMARC 
pass that DKIM would not also yield a DMARC pass, so we don't need it.  My 
judgement is that you are assuming too much perfection out of DKIM and the 
data doesn't support it.

Does that make more sense?

Scott K