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
