Subject: [Ietf-dkim] x= and DKIM replay

From: Evan Burke <[email-masked]>
Date: Wed, 2 Mar 2022 11:42:23 -0800

Hi,

I'm reading the section in rfc6376 on the x= tag, specifically -

INFORMATIVE NOTE: The "x=" tag is not intended as an anti-replay defense.

Could anyone shed some light on the reasoning for this, by chance? I note
that the spec for x= says "Signatures MAY be considered invalid [if past
expiration]", which isn't particularly strong guidance for how verifiers
should behave, but from my perspective, signature expiration could in
theory be an effective tool (among other defenses) to help reduce the
viability of replays.

Thanks,
-Evan

---

From: Steve Atkins <[email-masked]>
Date: Wed, 2 Mar 2022 20:10:07 +0000

> On 2 Mar 2022, at 19:42, Evan Burke <[email-masked]> wrote:
> 
> 
> Hi,
> 
> Could anyone shed some light on the reasoning for this, by chance? I note that the spec for x= says "Signatures MAY be considered invalid [if past expiration]", which isn't particularly strong guidance for how verifiers should behave, but from my perspective, signature expiration could in theory be an effective tool (among other defenses) to help reduce the viability of replays.

I think the reasoning was that a malicious replay attack could get a signed message and resend it very quickly, much quicker than the 90% bounds of how long it takes a typical bulk message to be queued and delivered - so setting expiration soon enough to prevent a malicious replay attack would also invalidate a lot of normally delivered mail.

So x= can’t be used to defend against competently handled, intentional replay attacks.

If I recall correctly (and I may not, it was a long time ago) the sort of lazy replays we’re seeing now weren’t really part of the threat modeling. Is x= potentially useful there? Could be.

It’d be worth looking at - whether DKIM checkers enforce it, what the spread on message sign time vs delivery time is, what the delay between original delivery and replay is. And whether the folks currently doing replays are likely to modify their behaviour if x= has any effect on them. I’d hate to roll out yet another mechanism that damages reliability of legitimate email while being trivially avoided by senders of malicious email.

Cheers,
  Steve