I was one of the M3AAWG 57 SF DKIM replay session organizers that helped put together the slides, so I can try to summarize some of the things in the slides. (I was hit with Covid so couldn't attend in person) M3AAWG has a confidentiality policy to permit greater knowledge sharing among participants so I will be sensitive and respectful of those concerns. So I apologize if I leave something out, but it might be because something was indeed sensitive or I suspect it is, and of course I missed the actual session, so don't know what was said in person. The following is a high level outline of the slides/talk:
- Introduction and description of DKIM replay noting the False-Negative and False Positive effects on reputation systems - Description of DKIM Replay detection techniques and effects observed by senders and receivers - Summary of existing DKIM replay mitigations based on tools available in RFC6376 - DKIM development history wrt DKIM Replay - M3AAWG 56 Brooklyn BoF / IETF 115 Dispatch proposals - Recipient in the signature proposals/drafts - Gather per-hop signatures proposals/drafts - Problem statement draft The session reuses some of the IETF 115 Dispatch DKIM Replay slides i.e. the introduction and proposals, meaning you can find the content there. Some interesting points: - Several senders described using Gmail Postmaster Tools for detection of DKIM replay - to look for changes to reputation, user reported spam, and volume - Summary of existing DKIM replay mitigations based on tools available in RFC6376 - DKIM header oversigning. Some discussion on which headers. - DKIM timestamp and expiry. Discussion of expiry durations. - Signature counting. Acknowledged False Positives which needs support to mitigate, but the claim is DKIM replay isn't a problem for that receiver i.e. highly successful. - Key rotation - DKIM replay was considered during development of RFC- hence the "x=" tag - Advice for DKIM WG success? To encourage folks to participate in the mailing list discussion thanks, -Wei On Tue, Mar 7, 2023 at 4:10 AM Laura Atkins <la...@wordtothewise.com> wrote: > All > > The DKIM working group is now active again (thanks Murray!). The chairs > wanted to send out a short note to welcome everyone and talk about our next > steps. > > Our first deadline is next month - to get a consensus problem statement > submitted on the IETF data tracker at > https://datatracker.ietf.org/group/dkim/ > > There is a current problem statement at > https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/. > Please take a moment to read through it and provide feedback. This chair > thinks we should not be providing solutions in the problem statement. We > should be primarily describing what the issue is and why we think the issue > is with the protocol. We will deal with solutions in the actual document. > > There was also a DKIM replay session at the most recent M3AAWG meeting. As > I understand it, they’re working on a BCP in parallel with the IETF. Many > folks are active in both groups. > > Due to M3AAWG privacy requirements, we are constrained in what we can > share from the meeting itself. However, if you were here and were on the > panel or part of the discussions, feel free to share with us some of your > thoughts on the problem, possible solutions and what your organizations > have done to address the issue. > > One of the panel members has shared the following from what he said at the > session: > > * RFC 6376 itself says "x=" is not a viable mechanism to deal with replay. > * There may only be a best practices solution, and not a protocol solution. > * DKIM has since the beginning kept itself completely separate from the > message transport. Several of the proposed solutions (including mine) take > leaps of varying sizes into the realm of DKIM knowing something about the > transport; the lightweight ones connect the message to the envelope > somehow, and the more heavyweight ones mean DKIM filters have to learn > about MXes and whatnot. We have to be absolutely certain that we want to > break that wall if we go this way, because once we do, there will be no > turning back. > > There was also a DKIM replay session at the most recent M3AAWG meeting. As > I understand it, they’re working on a BCP in parallel with the IETF. Many > folks are active in both groups. > > Due to M3AAWG privacy requirements, we are constrained in what we can > share from the meeting itself. However, if you were here and were on the > panel or part of the discussions, feel free to share with us some of your > thoughts on the problem, possible solutions and what your organizations > have done to address the issue. > > We will not meet in Yokohama due to the timing of being rechartered, but > we are considering a one hour interim in April if there appears to be > points of discussion. > > laura (as chair) > > -- > The Delivery Experts > > Laura Atkins > Word to the Wise > la...@wordtothewise.com > > Email Delivery Blog: http://wordtothewise.com/blog > > > > > > > _______________________________________________ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim