On Fri, Jun 13, 2025, at 12:46, Alessandro Vesely wrote: > On Thu 12/Jun/2025 18:03:51 +0200 Bron Gondwana wrote: >> (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* > > > Isn't the classical DKIM replay pattern something like this: > > DKIM2: i=1; [email protected]; [email protected]; > d=gmail.com *(correctly signed once)* > DKIM2: i=2; [email protected] [email protected]; > d=intermediate.com *(correctly signed thousands of times)*
Sure but you can very quickly tell that intermediate.com is the source of the bad traffic here, whereas right now you can do: [email protected] [email protected] and get a legit looking invoice from a legit company that sends out invoices by creating an account with them, grab the content of that (correctly signed message) and then send millions of DKIM signed messages: [email protected] [email protected] [email protected] [email protected] Sure the "To:" address in the headers is [email protected], but you can make that something plausible like "To: Renew Your Norton Subscription <[email protected]>". And there's no way right now for example.com to know if they were a Bcc on the message from paymentgateway.com or not. In the DKIM2 replay example you give above, it's clear that intermediate.com created the thousands of messages. In regular DKIM replay, paymentgateway.com only signed a message once, and sent it to the attacked-controlled throwaway at gmail. The remaining messages could be sent from anywhere in the world and they would still pass DKIM checks despite having a new destination that paymentgateway.com was never aware of. In DKIM2, someone who is signing is always are of who the next hop is, and how many distinct next addresses they're signing for. So if intermediate.com was an innocent forwarding service rather than the attacker, they would be able to rate limit their forwaring service to not be used to forward to thousands of different recipients. No hop can create a signature without knowing who the next recipient is under DKIM2. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
