On 13/11/22 03:05, Wei Chuang wrote:
On Fri, Nov 11, 2022 at 11:17 PM Roland Turner
<[email protected]> 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?
(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
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
