[Ietf-dkim] Re: DKIM with body length

[Philip Guenther <[e-mail]>]

On Thu, 23 May 2024, John Levine wrote:
> It appears that Murray S. Kucherawy  <[e-mail]> 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