Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted

[Jon Callas <[e-mail]>]

> On Aug 13, 2023, at 20:31, Jesse Thompson <[e-mail]> wrote:
> 
> If I understand based on my limited view of history, DKIM was designed for authentication between two hops. Signature survival across intermediaries was only achievable by encouraging intermediaries to not make any changes to the message "inside the envelope" such as standards-allowed MIME re-encoding (which, notably, prevents intermediaries from improving MIME interoperability).

I'm not the first to say it, but it was  the opposite. The original statement from the Domain Keys folks from Yahoo was that when your bank sends an email to you, your ISP can know that, even though it's bounced through your alumni association. It was *specifically* a three-hop thing in the distilled elevator pitch.

Remember as well that for two-hop sending, SPF was a preferred thing and there was a lot of conversation that tried to put them as competitors. We argued against that. I think it's pretty obvious that the two together are much better than either alone.

Here's a vastly oversimplified case. Consider someone who runs email on a small, NATted network. Under SPF, if a spammer sends a message from any host outward, it has the same path and thus passes SPF despite being spam. 
DKIM is domain-to-domain authentication, not user-to-user, because user relationships are complex. Here's a not-uncommon example:

Incoming email sent to info@domain goes into Alice's mailbox, via something akin to virtual users in Postfix. From time to time Alice sends a message from info@, without there being an actual user. The DKIM edge MTA signs it. That means that the mail architecture has to deal with the gap between Alice and that signing MTA. Any given setup is either a bug or a feature that they, not we, have to manage. Delegated email is a thing.

Pulling in what you said above that:

> [...] If DKIM is what is used by ESPs to authenticate message submissions, and the fallback for non-DKIM signed mail is to allow the submission, then certainly that is something spammers would leverage. That seems like an unlikely scenario since ESPs require other forms of authenticating message submission.

I'm not sure I really understand your case here.

DKIM authenticates the "administrative domain" of the sender, not the user. As noted above, the domain has to do a bunch of user management that's outside the scope of DKIM. That management can be strict (any user can only send email with their own From on it) or loose (any user can just telnet to port 25 and start sending emails from anything) or anything in between, and any decision has consequences the sysadmins have to adapt on their own.

I think you're saying more or less what I was saying, but I'm not sure.

As a last note, internal signatures like OpenPGP, and S/MIME, and anything else are inside the message and thus orthogonal to DKIM (and SPF).

Thus, SPF is a verification of the network path. DKIM is an authentication of the sending MTA. S/MIME etc. is an authentication of the sender. Each has its own failure modes, and each has weird edge conditions and gray areas. I look at it as they go up a stack of sorts -- network -> domain -> user.

	Jon