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
