On May 23, 2024 6:13:07 PM UTC, John Levine <jo...@taugh.com> wrote: >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. > For the Python module, my recollection is that I stared at RFC 6376, Section 5.4.1 and made the default set of header fields what it looked to me like the document recommended. I assume that since defaults are set before we know anything about the message to be signed, I included Content-Type since there's no way to know at that point if there will be an l= in the signature or not.
I'm confident I considered it enough of a corner case not to be worth adding complexity for. <https://datatracker.ietf.org/doc/html/rfc6376#section-5.4.1> Honestly, I think l= is an idea whose time has passed (if it ever existed at all). We ought to just kill it using the simplest procedural mechanism available. Scott K _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
