I was there at M3AAWG and concur with the chair's observations. I should also note I was part of the group who proposed restarting the DKIM WG at Dispatch IETF-115. My hope back then was that solving DKIM replay systematically could be a starting point for resolving more general email authentication problems that to me seems to be the root cause of the unresolved conflict in the DMARCbis WG. As such I'm saddened if this group concludes with just documenting a set of best practices to mitigate DKIM replay, as I don't feel this systematically resolves the authentication issues such as DKIM replay that I see today. Just before M3AAWG, I saw spammers had a campaign that used a combination of DKIM replay plus SPF upgrade. Going forward I suspect the spammers will keep using creative combinations of attacks driven by the Darwinian evolution afforded by the whack-a-mole approach we're stuck with.
FWIW regarding the idea of replacing ARC. I'll start by noting that ARC is a starting point and would argue it's easier to adopt ARC than to replace it, but if folks have a reasonable proposal, please publish a draft. If it helps resolve the general authentication issue, we're interested in exploring that too. We plan to publish the DARA results when they become available, whatever the outcome for this group. Also we can help with the Replay BCP as well. -Wei On Thu, Oct 26, 2023 at 3:48 AM Laura Atkins <la...@wordtothewise.com> wrote: > > Hello, All > > To remind folks where the group is, we currently have a problem statement > that needs to be discussed so we can reach consensus to adopt it. This > requires participation from members of this list. The current problem > statement is available at: > https://datatracker.ietf.org/doc/draft-ietf-dkim-replay-problem/ > > Per the charter (https://datatracker.ietf.org/wg/dkim/about/) the > consensus problem statement was due to be filed in the datatracker in > April. It’s now October and we’ve had no real discussion about the problem > statement for months. I think it’s fair to say this group has stalled. > There doesn’t seem to be any real interest in working on this problem. > > As much of the initial impetus for the group came out of discussions at a > M3AAWG meeting, I asked for a session during the most recent meeting > (October 2023, Brooklyn) to discuss whether or not there was enough > interest to move the IETF group forward. I asked for, and was granted, > permission to report back on the session here. > > My primary goal for the session was: > > Determine if there is a critical mass of people willing to commit to > moving the working group forward and if so > > - > > Get firm commitments from individuals about what they can do for the > process > > > - > > Collaboratively develop a plan of action on getting this done > > > If there was not a critical mass of people willing to commit to moving the > group forward, then I would take that into consideration and work with the > IETF. Any remaining session time would be focused on what MAAWG could do to > address the issue. > > I started off by asking the group if there was any confusion about what > the problem was. I then read my definition of a DKIM replay attack to > ensure we were all on the same page. > > “A DKIM replay attack is one where a bad actor sends a single message > through a high reputation system, gets a DKIM signature to a mailbox they > control. They then take that message and resend it, unchanged, through a > system they control that does not add a DKIM signature. This message > carries the original system’s high reputation d= value and may receive > better delivery due to that.” > > Members in the room added additional reasons for DKIM replay attack: > > - > > Damage the sender’s reputation > - > > Inflict damage on the sender’s infrastructure (not removing List-Unsub > headers can generate significant traffic on a sender’s unsubscribe > infrastructure, for instance) > - > > Use the sender’s reputation to warm up new infrastructure controlled > by the attacker > > > With most of the room agreeing these were the issues and problems, I asked > for a show of hands for who was willing to commit to coming to this working > group and participating. There were approximately 8 hands raised out of a > room of approximately 50 participants. > > It was my opinion 8 people does not constitute a critical mass of people > to move the working group forward and I said so. The IETF area director, > who was at the meeting, asked the group if they were happy about only 8 > people making the decisions for them. > > There was a discussion about next steps. Individuals working for some > large providers (both on the sending bulk mail side and on the large > receiving mail side) indicated they thought the problem was mostly > mitigated by things they implemented on their end. Other individuals > discussed potential problems and fixes. > > I then called for a rough consensus for a path forward of finishing the > problem statement, documenting the problem and some of the solutions folks > have implemented and then ending the working group. > > There was more discussion from various individuals highlights include: > > - > > Bulk sender A: Not sure how to solve the problem, they tried a few > things but it didn’t seem to have an effect and noted some reputation > problems even when DKIM signatures don’t verify > - > > Bulk sender B: Problem for them is currently at nuisance level, not a > big issue for them > - > > ISP A: Problem for them is currently at nuisance level, not a big > issue for them. Also, unlikely to state their solution on the IETF list due > to concerns about revealing their filtering processes. > - > > Monitoring Org: Sees examples of attacks. Issues include lack of > visibility in the ecosystem and lack of sender awareness and understanding > of the impact. > - > > I noted this was not an IETF (interoperability) problem and > suggested that the issue should be dealt with by M3AAWG or other > organizations. > > > I reiterated, again, the issue was getting people to show up through the > IETF process. We need participants to come to a rough consensus. One member > commented that they did show up but there was a lot of pressure to take the > problem back to MAAWG. I noted that there had been one very loud individual > who was repeatedly saying this, but he has left the list. Additionally, > myself and the other co-chair as well as the Area Director are monitoring > the situation if it reoccurs. > > After more discussion, including looking at a replacement for ARC, > possibly expanding the charter to address other authentication issues and > other digressions. I asked again for a show of hands of how many folks were > willing to come over to the IETF group to participate. This time there were > nearly a dozen hands. > > > I encouraged everyone to join the IETF list. I did comment that I’d be > counting subscriptions to ensure that folks did join the list. However, the > subscription page doesn’t have join-by dates so you’re all safe in that I > can’t do that. I do want to see some discussion and life on the list, > however. > > NEXT STEPS: > > As I see it, the next steps are to complete the Problem Statement document > describing what the problem is, what the effects of a replay attack are and > documenting some of the ways both senders and receivers have mitigated the > problem. > > I’d like to hear from folks on the list, both who were with us in Brooklyn > and folks who were not there about my proposed next steps. > > Laura (as chair) > > -- > The Delivery Expert > > Laura Atkins > Word to the Wise > la...@wordtothewise.com > > Delivery hints and commentary: http://wordtothewise.com/blog > > > > > > > _______________________________________________ > Ietf-dkim mailing list > Ietf-dkim@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-dkim >
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
