I've uploaded a draft describing for a specification that tackles the concepts listed below:
https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/ Feedback welcome. (Apologies for the formatting in advance as its a first draft) -Wei On Mon, Aug 22, 2022 at 2:53 PM Wei Chuang <wei...@google.com> wrote: > 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 >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
