On Wed, Feb 15, 2023 at 2:21 PM Michael Thomas <m...@mtcc.com> wrote:
> > There's also the question of whether "x=" is properly enforced. RFC 6376 > says verifiers "MAY" choose to enforce it. I think I asked about this at a > conference recently and was told that it's not universally supported by > implementations. > > Others have said that the enforcement is pretty good. But I have no way to > evaluate if that's true. > I don't think we're saying different things. I remember the point of the answer I got in that session being that most, but not all, implementations check or enforce signature expiration. But that means if "x=" is the solution we land on, we have to accept that a possibly-significant part of the ecosystem won't be able to use that solution. Then again, anything new we roll out is going to take a while to become universal anyway. > Going the route of some kind of duplicate signature detection alleviates > the risk of that approach, but also sort of inverts it: If you assume each > signature will only appear once, there's a window during which the first > signature works, and then a second window during which duplicates will be > blocked, but then that process recycles when the cache expires. That could > mean replays work if I just out-wait your cache. You also introduce the > risk of false positives, where a legitimate message tries to arrive in > separate envelopes with the same signature, and all but the first one get > blocked. > > I would imagine that the cache should be valid for a small x= expiry. > That's really a tuning problem on the sending domain. > Possibly. I get the impression that a good chunk of the industry would like something more from us than "you have to tune this" (i.e., something laying out specific values), but maybe we can't do anything beyond general advice because there are too many other variables at play. RFC 6647 avoided laying out specific values for greylisting, for example. > There are *tons* of external dependencies on the filtering MTA. I really > can't imagine that this would be the straw that breaks the camel's back. > Depends (as I think Scott said) on the size and resources available to the operator, and how much they're a target of this attack. We've generally shied away in the past from solutions of the form "you have to be at least this tall to play". -MSK
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
