On Thu, Jun 12, 2025, at 10:53, Dave Crocker wrote: > On 6/11/2025 8:28 PM, Bron Gondwana wrote: >> Legitmate alias: [email protected] -> [email protected] -> >> [email protected] >> Source email from: [email protected] >> >> DKIM2: i=1; [email protected]; [email protected]; d=bbiw.net >> DKIM2: i=2; [email protected] [email protected]; >> d=fastmailteam.com >> DKIM2; i=3; [email protected] [email protected]; >> d=fastmailteam.com > > > OK. That's the 'legitimate' scenario. > > Now, how does an illegitimate, Replay scenario look different, where DKIM2 > makes clear the distinction between a legitimate sequence from an > illegitimate (spamming) one? >
Um... like "not that". Seriously, I don't actually understand what you're asking here. I see this as equivalent to a username/password based login where "a valid login involves the presentation of a correct username and password pair". If you don't have both, you can't log in unless the system is buggy. Ok, let's write out some examples... Suppose I had a copy of the above message, and wanted to illegitimately replay it to our good friend Pete. Further, let's assume I didn't have the private keys for bbiw.net or fastmailteam.com* (this is an axiom - if you have the key, you can act as that domain, which is not replay)* I could send the message with zero of those DKIM2 headers, or with one, or with the first two, or with all three, or any other combination of them with gaps -- but the `rt=` woudn't be Pete, or his domain, so it would be clearly replay to him when he received it -- because a legitimately forwarded message would have had another DKIM2 header added with `[email protected]`, and none of those messages would have that. Here's some thing I could do which would have failing signatures: DKIM2: i=1; [email protected]; [email protected]; d=bbiw.net *(correctly signed as above)* DKIM2: i=2; [email protected]; [email protected]; d=*fastmailteam.com* *(with a failing signature)* DKIM2: i=1; [email protected]; [email protected]; d=bbiw.net *(with a failing signature)* And here are some examples which fail the invariant properties of how DKIM2 headers work, meaning that they are invalid chains: (mis-aligned i=2/mf= and i=2/d=) DKIM2: i=1; [email protected]; [email protected]; d=bbiw.net* (correctly signed as above)* DKIM2: i=2; [email protected]; [email protected]; d=*badguy.com* (mis-aligned i=1/rt= and i=2/d=) DKIM2: i=1; [email protected]; [email protected]; d=bbiw.net *(correctly signed as above)* DKIM2: i=2; [email protected]; [email protected]; d=*badguy.com* (sneakiest: mis-aligned i=1/rt= and i=2/d=, but with an intermediary fake hop so the final hop looks clean) DKIM2: i=1; [email protected]; [email protected]; d=bbiw.net *(correctly signed as above)* DKIM2: i=2; [email protected]; [email protected]; d=*middledomain.com* DKIM2: i=3; [email protected]; [email protected]; d=*badguy.com* (mis-aligned all sorts of things) DKIM2: i=1; [email protected]; [email protected]; d=bbiw.net *(correctly signed as above)* DKIM2: i=2; [email protected]; [email protected]; d=*badguy.com* (duplicate i=1) DKIM2: i=1; [email protected]; [email protected]; d=bbiw.net *(correctly signed as above) *DKIM2: *i=1*; [email protected]; [email protected]; d=*badguy.com* (duplicate i=2, one of each aligns each way) DKIM2: i=1; [email protected]; [email protected]; d=bbiw.net *(correctly signed as above)* DKIM2: i=2; [email protected] [email protected]; d=fastmailteam.com *(correctly signed as above)* DKIM2: *i=2*; [email protected]; [email protected]; d=*badguy.com *DKIM2: i=3; [email protected]; [email protected]; d=*badguy.com* *Here is what I can't do as an attacker:* DKIM2: i=1; [email protected]; [email protected]; d=*bbiw.net* *(with a passing signature)* OR DKIM2: i=1; [email protected]; [email protected]; d=bbiw.net *(correctly signed as above)* DKIM2: i=2; [email protected]; [email protected]; d=*fastmailteam.com* *(with a passing signature)* Because I don't have the keys to be able to generate those headers. ... I invite you to find holes in my logic here, or propose an alternative illegitimate (spamming) process which would pass a DKIM2 checker that obeyed the following rules (all of which work fine for legitimate mail flows): • There must be at least one DKIM2 header field. • The DKIM2 header fields must be monotonically increasing without gaps (if `i=3` exists there must be exactly three header fields with `i=1`, `i=2`, `i=3` - recurse as appropriate). • There MUST be no duplicate DKIM2 header fields with the same `i=` number. • For all DKIM2 header fields; the domain part of `mf=` MUST equal the domain `d=` • For the DKIM2 header field where (i==1) the domain of the From/Sender address MUST equal the domain `d=` • For the DKIM2 header fields where (i>1) the domain part of the `rt=` from the DKIM2 header field with number i-1 MUST equal the domain `d=`. Any receiver must make the following additional assessment on top of checking compliance with the above rules, for any incoming message with DKIM2 header fields, before accepting it: • The highest numbered DKIM2 header is correctly signed (public key exists in DNS, verification passes) • This system has a private key for which the public key is published in the DNS for the domain in the `rt=` of the highest numbered DKIM2 signature. These two rules are necessary in order to be able to create a signed bounce message if any further tests fail. At this point you can safely accept the message, because you can reliably generate a bounce without any backscatter or amplification risks (if bounces weren't signed then anyone could falsify them, and if the highest level DKIM2 signature isn't correct then anyone could falsify the address to send bounces to, so you couldn't send them without risking creating backscatter. I can show working on this as well if it's not clear). Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
