On Sat 04/Feb/2023 00:44:35 +0100 Michael Thomas wrote:
On 2/2/23 4:06 PM, Scott Kitterman wrote:
There is an existing draft of a problem statement, so there's at least a
starting point to consider. I think discussion about what's needed is
probably more useful relative to a specific draft than in the abstract:
https://datatracker.ietf.org/doc/draft-chuang-dkim-replay-problem/
Other than removing the ARC references, this seems like a good start.
ARC is very similar to DKIM. Saying that it can have the same problem doesn't
seem out of place to me.
I sort of like the proposed solution space, but several of them could be tried
today or have huge downsides. Bcc, for example, would be a security fail if it
were in the message headers. Caching signatures could be tried today but I
don't see how that can be distinguished from, say, a mailing list.
But it could be rewritten in terms of not solutions but possible angles to
attack the problem with pros and cons. It may well be that a preponderance of
evidence could be useful. We could list off a bunch of other possible clues
too. For one, what is the reputation of the To: address's domain? There are
surely more.
I'd drop Section 4. We have discussed those topics, but enumerating them in
the problem statement sounds like establishing explicit limits to the solution
space.
Rather, I'd include a report of actual incidents, possibly showing full message
contents and estimated fallout dimensions.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
