[Ietf-dkim] DKIM replay mitigations

[Wei Chuang <[e-mail]>]

Hi,
One of the known security challenges in DKIM is its vulnerability to replay
attacks as already mentioned in Security Considerations section 8.6
<https://datatracker.ietf.org/doc/html/draft-ietf-dkim-rfc4871bis#section-8.6>,
and has been raised at recent M3AAWGs as a significant challenge.  I'd like
to propose a couple of concepts for dealing with DKIM replay.  Depending on
where the conversation goes, I can get into proposals for technical
specification level proposals.

DKIM replay typically takes advantage of capturing a DKIM signed message
from the inbox and then rebroadcasting it out to many users.  Taking that
observation there are a couple of directions for mitigations.
1. We can try to detect and prevent the recipient amplification.  One way
may be to specify that the sender must always DKIM sign for the who the
intended recipient is including through mailing lists and forwarding
scenarios, in such a way that the receiver can check for this.  If the
intended recipient verification fails, then it may be an indication of
replay.  This must work for multiple forwarding hops and enterprise
scenarios, and when forwarders don't participate.
2. Distinguish signed messages in the inbox versus those in transit.  If we
see messages that were signed messages meant to be in the inbox, suddenly
in transit again, this likely indicates a replayed message.
3. Strengthen message digital signing to be replay resistant.  Currently
DKIM signature's identity just says it is associated with a particular
sender.  Perhaps we ought to tie the signature back to a particular SMTP
transaction by signing for both the sender, receiver and timestamp.  We
could add more specification around the timestamp to make it more workable
in the email distributed forwarding system for replay detection.  Put this
signature in a framework such as ARC that describes forwarding hops
better, so that receivers can make use of those identities with
forwarding.  Using ARC as the signing framework also helps proposal 1).
Again consider when receivers don't participate.  (This is a highly complex
scenario and likely I'm missing important details in trying to summarize)

All the while, using ARC as a framework may allow future support for
another long standing issue, which is working on message modification while
forwarding, in particular for mailing lists.  The proposal
draft-kucherawy-dkim-list-canon-01
<https://datatracker.ietf.org/doc/html/draft-kucherawy-dkim-list-canon-01>
provides
a framework for handling common mailing list modifications by identifying
those modifications.  Putting it into ARC, may generalize this by
identifying who made the modifications and be able to tolerate multiple
such modifications such multiple mailing list expansions.

Looking forward to your initial thoughts about feasibility and interest.
-Wei