On Tue, Jun 10, 2025, at 11:49, Dave Crocker wrote: > On 6/9/2025 9:44 AM, Bron Gondwana wrote: >> I think this is the root of our disagreement. I fundamentally disagree that >> there will be legitimate scenarios that match replay abuse scenarios with >> DKIM2. > > > When there is a rich set of plausible usage scenarios that cover legitimate > and bogus examples, and a careful analysis of how DKIM2 will prevent replay > and permit legitimate reposting, for each of them, then perhaps your faith > will be justified. > > So far, assertions of such faith lack a publicly-shared basis. >
*I would like to flip this question, and ask you to demonstrate a case in which replay will be possible with DKIM2. * Because I don't see it. Not a replay in which the source domain or destination address is faked, without access to the source domain's key. If nobody is able to show such a case, then I would say that the "prevent replay" case is pretty strong. Which leave the "permit legitimate reposting"; for which I would say "passing DKIM2 signatures are treated as legitimate, and if you have the key for a domain and can calculate the delta from the message which you received, then you can create a passing DKIM2 header, so do that". I will stipulate: this property of unforgeable-without-key for all sources and destinations is ALSO present on the updated DKOR where there are i=<n> headers for each hop. At which point the remaining advantage of DKIM2 is being able to see that no hop lied about the content of the message that came before it. ARC also provided the "you can see that a hop didn't change anything" - however if any hop did change something, then the contents of earlier messages could be absolutely anything, including completely different content. This means that a bad hop could claim to just be putting a signature on the message, but actually have replaced the entire message with new content - using legitimate DKIM and ARC headers from a totally different message which still passed the verifier. DKIM2 doesn't have that failure mode, because you can examine the delta and you know exactly what the bad hop did; and that it wasn't innocently being a mailing list forwarding on the bad message from earlier. This is a big deal. I think it's necessary; hence why I'm arguing for it. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
