On Tue, Feb 14, 2023 at 11:44 AM Michael Thomas <m...@mtcc.com> wrote:
> At maximum, isn't it just the x= value? It seems to me that if you don't > specify an x= value, or it's essentially infinite, they are saying they > don't care about "replays". Which is fine in most cases and you can just > ignore it. Something that really throttles down x= should be a tractable > problem, right? > Remember that the threat model is: 1) send a message through A to B, acquiring A's signature 2) collect the message from B 3) re-post the message to C, D, E, ... These days, this attack is complete within seconds. If you select an "x=" small enough to thwart this, you have to expect that all legitimate deliveries will happen even faster. But email delivery can be slow for lots of legitimate reasons. So I would argue that "x=" alone can't really solve this problem without introducing other constraints that we don't really want. 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. 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. > But even at scale it seems like a pretty small database in comparison to > the overall volume. It's would be easy for a receiver to just prune it > after a day or so, say. > It creates an additional external dependency on the SMTP server. I guess you have to evaluate the cost of the database versus the cost of the protection it provides, and include reasonable advice about what to do when the database is not available. -MSK
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
