It appears that Murray S. Kucherawy <superu...@gmail.com> 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. I guess this isn't as obvious as the authors of 6376 thought since we still have at least one person on this list insisting that you don't need to sign C-T. 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. Requiring that the l= cover some minimum percentage of the message is helpful but not that helpful, since you could add a short part with a phish URL to a long message and probably still pass the percent rule. On the third hand, I'm looking at mail in the IETF archives from Verisign which has had DKIM signatures the l= tag since shortly after the time they switched from Google to Ironport in late 2016. The set of headers it signs is inconsistent. It always includes MIME-Version, sometimes Content-Transfer-Encoding, and never Content-Type. So we do have at least some examples where this bug exists. R's, John _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
