On Sun, Nov 13, 2022 at 8:50 PM Roland Turner <roland= 40rolandturner....@dmarc.ietf.org> wrote:
> On 13/11/22 03:05, Wei Chuang wrote: > > On Fri, Nov 11, 2022 at 11:17 PM Roland Turner <roland= > 40rolandturner....@dmarc.ietf.org> wrote: > >> >> >> 1. Unless one or more of the larger receivers (a) has a useful tool >> to help with this problem, and (b) is willing to share operational >> experience, then we risk creating yet another lengthy, academic exercise >> (remember ADSP?). I'd suggest that this might be enough reason by itself >> not to proceed. >> >> See the dispatch slides here > <https://datatracker.ietf.org/meeting/115/materials/slides-115-dispatch-dkim-replay-problem-and-possible-solutions> > for > operational experience and impact for at least Gmail and Fastmail (the > presenters). See the introduction. > > Thanks, but that deck appears to contain no information about operational > experience or impact for either organisation, it merely describes the > attack and surveys the proposed improvements to defences. Also, while > Bron's role at Fastmail is clear, your own involvement with Google's > receiving of email is not: are you in fact part of Google's email abuse > control function? > Yes. As to my role in this, I am a Gmail delivery team lead with responsibility over the email authentication systems. The introduction in that slide deck represents the consensus description between the anti-abuse and delivery teams with feedback from Bron and others as to the behavior and impact of DKIM replay, and was based on a longer version presented at the M3AAWG 56 BoF that was shortened to fit into the allotted time for Dispatch. I can also say that Gmail is very interested in seeing a DKIM replay solution be developed in the IETF. Depending on how this goes, if the solution is technically sound and feasible, yes we will invest in prototyping the specification. -Wei > (I do not wish to belittle you, however the difference between involvement > by someone who has spent years of their life solving this problem for real > at scale and involvement by an interested engineer who merely happens to > work for the same organisation is immense. Most of the fruitless debate on > this problem over the last 20 years has been by people who are not > responsible for defending large numbers of mailboxes pursuing merely > plausible theories.) > > > Gmail saw DKIM replay ramp up in late 2021 and early 2022 but the impact > has been reduced recently perhaps due to the mitigations the industry has > put in place. > > Right. What I'm suggesting is that undertaking work in an IETF WG is not > wise if the people implementing those mitigations are not actively involved. > > > That said, the problem in the specification still remains. > > That's not enough reason to charter work on it in an IETF WG. There has to > be some reasonable chance of the work improving the situation. Without > direct involvement by practitioners at the decision-making end of message > transfer, I'd suggest that this is most unlikely. > > > I am not aware of any tools to help with the problem, hence the request to > Dispatch to do this work. > > I'd suggest that that, by itself, may be enough reason *not* to proceed. > > > I (and the authors of the other drafts) believe that DKIM replay can be > detected via some of the characteristics that the spammers exploit (see > concepts I posted earlier around Nov 11, 2022, 2:18 PM) but the current > email authentication protocols don't look for that. > > As the discussion is currently about whether to undertake the work I've > resisted critiquing the proposals directly, but as part of establishing > whether there's a "there" there, I'd point out that all but one of those > things is either redundant (vs. say ARC), unacceptably harmful (we use DKIM > *in > the first place* to facilitate forwarding outside of the > domain-registrant/sender's control), or both. The exception is a > standardised mechanism to allow a sender/signer to indicate the > [approximate] number of intended recipients, with which receivers might > make fact-based decisions about when to recognise an instance of this > particular attack, but without the active involvement of large receivers > this is still academic, just as SPF -all, DomainKeys o=~, and ADSP > discardable were. > > Perhaps a different tack: if you're not part of Google's email abuse > control function, are you able to recruit people who are? > > - Roland > > > _______________________________________________ > 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
