BIMI and DMARC Can't Save You: The Overlooked DKIM Exploit

Aw geez, that&#x27;s a <i>really</i> nasty bug.<p>So with DKIM you&#x27;re signing some headers and the body. DKIM has a &quot;body length&quot; tag, &quot;l=&quot;. Contrary to its name it doesn&#x27;t say anything about the body length, but it specifies the <i>length of the content being signed</i> - so an attacker can add random crap to the end of the message without invalidating the signature.<p>This combines with multi-part email to essentially let an attacker completely overwrite the message body.<p>To make it even worse, the spec is written quite vague and heavily suggests that inserting &quot;l=&quot; is mandatory, despite also mentioning cases where it isn&#x27;t present. That&#x27;s pretty much <i>asking</i> for trouble.<p>And of course all that is made a Serious Problem because DMARC is fundamentally broken and considers a message valid when <i>either</i> SPF <i>or</i> DKIM passes - so it&#x27;ll happily accept a message with a valid DKIM signature coming from a host who fails SPF.

Shameless plug: My DMARC Checker at <a href="https:&#x2F;&#x2F;dmarcchecker.app&#x2F;" rel="nofollow">https:&#x2F;&#x2F;dmarcchecker.app&#x2F;</a> displays a warning message if it encounters a DKIM signature header with an &#x27;l=&#x27; tag:<p>&quot;The &#x27;l=&#x27; tag limits how many bytes of the email body are included in the body hash. This may allow an attacker to alter&#x2F;expand the message in a way that it still passes DKIM validation.&quot;<p>Additionally, the tool alerts you to the use of weak RSA keys or SHA1.<p>By the way, less than 0.4% of all emails checked make use of the &#x27;l=&#x27; tag.

BIMI is useless.<p>SPF and DKIM are flawed.<p>DMARC is a patch on top of SPF and DKIM.<p>If you want to be able to trust email, you need a trustworthy PKI. If you want to communicate with people who don&#x27;t or can&#x27;t participate in the PKI, you need a mail client that rigorously and clearly distinguishes the anonymous from the verifiable.<p>Given the existence of two parallel email systems, some people will run gateways that create artificial verification of non-verifiable messages. Now you need to figure out reputations for all the gateways.<p>In the end, you always end up with spam and forgeries.

This is an excellent writeup, and great example of responsible disclosure done right.<p>However, I can&#x27;t get over the clickbait title. This seems like a real cheap shot at BIMI, and DMARC for that matter.<p>BIMI never pretended to be a &#x27;security&#x27; protocol of any kind. It&#x27;s a branding opportunity to incentivize DMARC adoption. That&#x27;s what is literally explained on the front page of the BIMI workgroup website [0]. I won&#x27;t go into the discussion whether the price of a VMC is justifiable or not, but saying &#x27;BIMI can&#x27;t safe you&#x27; as if BIMI ever promised it would is just ridiculous in my opinion.<p>DMARC on the other hand is more of a policy protocol than an additional layer of security. Yes, it does strengthen the underlying protocols (SPF &amp; DKIM) a little bit by adding the alignment requirement, which more-or-less patches the worst flaws of both protocols, but it doesn&#x27;t magically make email secure. Saying &#x27;DMARC won&#x27;t safe you&#x27;, as if DMARC was somehow ever capable of fixing 0-days in the underlying protocols is, again in my opinion, ridiculous.<p>I get that the company is proud of the discovery of this security flaw, and that such a publication is a great opportunity them to get your name out. But I just can&#x27;t shake off the thought of the engineers having to witness some guy from PR slapping a cringy clickbait title on their otherwise excellent work.<p>[0] <a href="https:&#x2F;&#x2F;bimigroup.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;bimigroup.org&#x2F;</a>

I&#x27;m impressed that email with POP, SMTP and slightly later, IMAP has served up so well for 30+ years, but by golly, it&#x27;s an uphill battle running any sort of mail service yourself these days. I starting to understand the businesses that (claim to) run without email to and from customers.

Can someone explain to me why this was only disclosed to Microsoft, Google and Apple? Is this considered responsible in this case?

The over signing part of DKIM is really confusing. It&#x27;s easy to overlook and can blow the whole thing wide open. And yet it&#x27;s not the default, presumably for some reason, so it&#x27;s unclear what happens if you just go ahead and over sign every header. Is it surprising people get this wrong?

What is the intended use case for the l= parameter? Why not sign the entire email all the time? Why would anyone want to use l=1 ?!!1

Interesting, does anyone have a list of known providers vulnerability to this in the past? I&#x27;m thinking big providers like G-Suite, Office 365, Zoho, Fastmail, etc.

This is all ridiculous.<p>Maybe I’m not that bright, but it seems like you don’t need <i>that much</i>.<p>1. A TXT record containing a public key and a unique identifier<p>2. Message Body and Headers hashed with SHA512, and then the hash is encrypted with the private key to the TXT record. This hash, and the address for the public key, is then added to the headers as the only permitted “untrusted” headers<p>3. Email receiver, if present, ignores all headers if the two are present. Looks up DNS public key, decrypts hash, removes the two headers, checks hash matches. If so, contents trusted if:<p>4. The domain the email was sent from, and claims to be sent from, is the same domain hosting the TXT record.<p>What did I miss?