On Thu, 23 May 2024, John Levine wrote: > It appears that Murray S. Kucherawy <[email protected]> said: > >I've read the middle part a few times and I don't understand either the > >attack or the proposed mitigation, so I think some examples might help. > > The attack requires l= and an unsigned Content-Type header. > > If Content-Type isn't signed, the bad guy can change the part boundary > string and then add new parts with the new boundary at the end. The > entire original message, which is all that the l= covers, is ignored > as junk before the first boundary.
There's a related, though much less general, attack that works even if you don't use the l= tag: on a message which has nested multiparts, there are multiple potential delimiters that will look legit to a MIME parser, so if you don't sign Content-Type** then an attacker can change the delimiter from the outermost to a inner delimiter and make it appear that the sender directly sent just that inner content, possibly resulting in misattribution. ** or don't over-sign and clients use the first found... > On the other hand, I see that the perl and python DKIM modules sign > the MIME Content-* headers by default. Do you remember what opendkim > does? A quick look at the code wasn't too enlightening. Unfortunately, the most recently released version of opendkim doesn't sign any MIME headers by default. Lacks RFC 8058's List-Unsubscribe-Post too. Philip Guenther _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
