On Sun, May 19, 2024 at 9:27 AM Wei Chuang <weihaw= 40google....@dmarc.ietf.org> wrote:
> As many of you know there was a DKIM security vulnerability disclosure > Friday around the signature header body length tag "l=". The blog post is > here: https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/ > The authors state that an adversary can append a malicious footer to a > message with DKIM w/body length, then rewrite the Content-type header mime > delimitter, that will cause the apparent body to be that of the footer but > will authenticate as the original DKIM signature. This enables spoofing > the original sender's identity, hence can spoof DMARC and BIMI but with a > malicious message body. DKIM RFC6376 section 8.2 <http:///> already > describes this problem, which the authors acknowledge, but according to > them what is new is that there actually is mail traffic with DKIM-Signature > w/body length which includes Fortune 500 companies. > > [...] > As everyone seems to be agreeing, there's nothing new here. The only concern is that people actually do use "l=" for some reason in spite of the warnings. There's talk here of revising RFC 6376 to remove the tag. That's certainly one option, and it's worth noting that we did consider doing so when RFC 4871 became RFC 6376 (STD 76), but as I recall a constraint of removing a feature when upgrading something to Internet Standard states that the thing you want to remove has to be unused, and "l=" was found to be in non-zero use, so we were forced to keep it, even with the warnings. Also, deleting it from the specification now will in my view not be much of a solution given: (a) Inertia will mean "l=" is generated and/or accepted for a long time to come no matter what we say or do; and (b) Even if (a) weren't true, "l=" then becomes an unrecognized tag at verifiers, which will mean those signatures break and we have an interoperability problem (though likely a tolerable one). DKIM also warns signers to sign anything that goes to the content or structure of the message. RFC 4871 used to include a list of fields that SHOULD be signed, and I think Content-Type was one of them; RFC 6376 removed the explicit list in favor of more abstract guidance that should lead anyone toward the same original list at least. So even that aspect of this attack was anticipated. It seems to me this is solved easier with local policy changes. DKIM allows for rejection of signatures for any local policy reason, so operators could just start rejecting messages that use "l=" or that fail to sign/oversign "Content-Type". This could be an Informational document rather than one that updates the standard. Dave Crocker mentioned that there is a pathway to do a narrow update to the > RFC6376 as an individual submission. I agree that it is a good idea as > hopefully a narrow update can be done relatively quickly. I understand > that body length "l=" was meant to help DKIM tolerate adding a footer > that a mailing list might do and that there is pressure from the DMARC > world to think about this. Perhaps that still can be done except in a > better secure way, and that work could be a separate document to permit it > time to figure out how to do it. One idea is to have the forwarder sign > with an ARC Message-Signature and would take ownership of the new message. > The forwarder would describe the offsets to recover the original body > length and some receiver can validate the original DKIM signature. Those > offsets will also describe the forwarder's contribution to the message. > There would also be problems around secure footer modification of > Content-type header that are unsolved e.g. what to do if Content-type is > oversigned. All this work might be good candidates for the newly chartered > Mailmaint WG. > Before we make suggestions about ARC, I would strongly suggest someone try that as a solution or mitigation to this problem. I would not like us to publish something that shouts about this being a serious problem but then presents untested solution(s). And frankly, I'd like to see ARC graduate out of Experimental status if that's what we want to put forward as a solution. As to MAILMAINT as a venue, we'll have to see whether the community thinks this is "big" or "small"; if the former, it should probably get its own WG. -MSK, presently hatless
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
