On Tue 08/Aug/2023 16:47:23 +0000 Murray S. Kucherawy wrote:
On Tue, Aug 8, 2023 at 9:25 AM Alessandro Vesely <ves...@tana.it> wrote:
On Tue 08/Aug/2023 14:47:37 +0000 Murray S. Kucherawy wrote:
On Tue, Aug 8, 2023 at 7:17 AM Scott Kitterman <ietf-d...@kitterman.com> wrote:
That's true of all indirect mail flows. It's not a distinguishing feature
of the attack.
Quite right, making this harder to pin down.
But, to Alessandro's point, I do think the description in the document is
accurate.
Agreed, except for narrating an actual case. However widespread, there
are people like me who never recognized a replay attack.
What do you mean by "narrating an actual case"? Section 1.1 does contain a
narrative of how one executes the attack.
Yes, it says DKIM Replay is impossible to detect or prevent with current
standards and practices. However, it must have been recognized well enough
to grasp the described modus operandi.
Are you talking about a narration of how one detects the attack, as
distinct from a typical indirect mail flow?
I guess a replay attack must engage multiple abuse teams, because of the
size. Is the alarm triggered by users reporting many messages as spam?
How many abuse teams at different organizations get involved? What is the
size of the attack? What emergency measures are taken? At what stage does
it become clear that a spam tide is a Replay Attack? What difference does
it make such recognition?
I admit these questions are much out of curiosity, but knowing those
details could help framing possible solutions. Being completely ignorant
about operations at large providers, I don't understand why the research
steadfastly turns toward hard flying protocol changes rather than, for
example, also investigating how to tune signing policies based on exchanged
user reputation, or fast recognition of signed body hashes when they
re-emerge from unexpected sources.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
