On 2/10/23 2:10 PM, Evan Burke wrote:
On Fri, Feb 10, 2023 at 1:55 PM Michael Thomas <[email protected]> wrote:| taking advantage of the flexibility in DKIM to | selectively sign headers, the spammer may intentionally leave out | certain headers such as To:, and Subject: that can be added in later | without damaging the existing DKIM signature. I think this needs to be explained. It isn't obvious to me how they would manage to do that. The header fields signed are under control of the signer, not the original author. How do the attackers coax the provider's signer into not signing certain fields? By leaving them out. Many DKIM signers, having observed this vulnerability, have started oversigning headers to prevent that.I think the draft should flesh this out a bit more. I mean, are they just doing a bcc without a To: address? Are there other mechanisms? Is that suspicious or is it a legit behavior? I don't think I've seen a message without a To: address (or at least a legit one).I more frequently saw replay attackers adding a second set of certain headers to the message during replay. As long as the original header was still present and matched the signature hash, the signature was intact. Regardless, oversigning solves both cases.
Then it should be in the problem statement of what they are doing. A well documented account of the current cat and mouse game would be really helpful. Speculation on where it it may go would be helpful too. I'm sure that text would be appreciated too. (if it isn't obvious, this draft seems like a good way forward on the problem statement to me).
(again, this will be important to inform possible BCP things, and in the case of To: and Subject: to possibly making them required to be signed in a protocol change. certainly that might be an interesting discussion)The M3AAWG BCP will cover recommended header signing/oversigning policies. I'll make sure that's shared here when it's published.
Any idea when that might drop? Mike
_______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
