At least as I read it, I don't think you are describing the same issue as RFC 8376, Section 8.6. It describes the concern as "banking on the reputation of the signing domain (e.g., a large popular mailbox provider) rather than its own". I believe that's meant to describe an unaligned (in a DMARC sense) message, which seems different than what you are describing.
Many normal email operations seem difficult to distinguish from the case you are trying to address. Signing fields in the envelope may be enough to break replaying, although it would have other negative consequences. Scott K On October 3, 2022 11:40:55 PM UTC, Wei Chuang <weihaw=40google....@dmarc.ietf.org> wrote: >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 >> _______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
