On Thu, 23 May 2024, John R Levine wrote: > On Thu, 23 May 2024, Philip Guenther wrote: > > 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... > > I would prefer not to go there. A message with two Content-Type headers > or two Subject headers or Date or Message-ID and so forth is not a valid > message, and a DKIM signer or validator should just say no.
I'm not familiar with DKIM validators that also apply those sorts of "too many instances of a field" rules. Perhaps it would make sense to talk about that in a revision of the DKIM rfc, bringing it to the attention of those writing validators that enforcing those limits for any signed headers may be necessary in order for the DKIM signature to actually protect what people expect it to protect, given the many clients which do *not* enforce those limits. This current round of visibility on risks of the l= tag and not signing content-type is a moment where *signers* are being prodded and updating their configurations. For those signers who don't want to wait until all their recipients' validators are updated, oversigning is an option to get protection now. Philip Guenther _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
