On Wed, Sep 16, 2026, at 04:51, Vittorio wrote: > Concretely, with duplicate keys: a recipe object containing two entries > for the same header field name is not rejected by a conforming parser > and RFC 8259 leaves the resolution undefined. One implementation takes > the first, another the last. Both then reconstruct a different previous > header state from the same signed bytes and compare it against the hash > declared by the preceding hop. One reconstruction matches; the other > does not.
I'm trying to parse this into a coherent attack vector. What could a bad actor do with this? Launder a bad messages as good somehow? Launder reputation? Consider a message from A to C via B. B being the canonical "Bad actor". A is sending an invoice with bank account ABC123 and B wants to change it to say "bank account XYZ789" and still validate as being from A. So here's B's goal. Create two variants of the message. 1) original reconstructs as "bank account XYZ789" - aka, B didn't modify the bank account. 2) original reconstructs as "bank account ABC123" - aka, A's Message-Instance validates. Those, as far as I can see it, are the kinds of things that an attacker might want to change. They can't change the content their OWN signature signed, because that doesn't even go through a recipe. That's hashed directly into the Message-Instance they sign, and sent to C. So the risk here is that C somehow has a validator which runs two disjoint passes - one applies the recipe and checks that it didn't change anything risky but doesn't check the earlier Message-Instance applies, the other applies the recipe and validates the earlier Message-Instance but doesn't compare the content. It MUST be both. Otherwise the security hole is big enough to drive a truck through. Either you blindly trust any changes B made (in which case you'll pay the invoice to the wrong account) or you blindly trust the recipe without validating the earlier Message-Instance (in which case B can just lie, no need to create a recipe which even tries to be valid). I mean, it's possible. It's really bad coding, but I guess it's possible. Luckily Richard's coming-soon change to make any duplicate key be a syntax error and grounds for rejecting the message will solve it. Unless both validators are bogus in which case see the earlier failure cases. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
