Regarding RFC6376 l= tag, I was hoping that Taavi Eomäe who sometimes posts on this list would answer directly as he and his team wrote a blog post <https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/> about the dangerous vulnerability the DKIM body length feature introduces. As noted in May 2024, the authors found many infrastructurally important senders' emails had DKIM with body length, and with these emails it was possible to completely rewrite the user visible content yet would indicate a DKIM pass. That result could then indicate a DMARC and BIMI pass as their example illustrated. On this public list I'm going to leave up to the imagination of the reader what a malicious party could do here with that malicious content, but I would agree with the blog authors that consequences could be rather bad. And like the authors suggest, it isn't just a few confused senders. While percentages are small, the importance of the senders, presumed sophistication and consequence of spoofing those emails would be surprising to many having looked at the data on who the senders that use this feature are. (see the blog post for examples) There was a long mail thread <https://mailarchive.ietf.org/arch/browse/ietf-dkim/?q=dkim%20body%20length> on this list (ietf-dkim@) to draw attention to this vulnerability. Since then a bunch of us in industry have been coming together to make improvements and some of that work is described in draft-gondwana-dkim2-modification-alegbra <https://datatracker.ietf.org/doc/draft-gondwana-dkim2-modification-alegbra/>. There are other ideas too but are waiting for this working group to kick off due to prohibition on technical discussion until then. The key difference between RFC6376 l= and Bron's draft is that the forwarder making the modification takes ownership of the modification and this provides attribution. With RFC6376 l=, anyone can make the change without attribution which lets a malicious party slip right in. A second difference noted by the draft is identifying the changes in a reversible, verifiable way. A third point is around the suggestion later in this thread about incremental changes to RFC6376 vs a new authentication mechanism. The problem with incremental changes is that they are inherently optional, and very soon you'll have many combinations of features in use that hurts interop. And once optional it will take a very long time if at all to go away. I still see DKIM body length being used yet at a lower rate, having dropped by half after Taavi's May 2024 blog post but some decline after that but definitely not trending towards zero. Fourth, going back to RFC6376 l= tag, the security section <https://datatracker.ietf.org/doc/html/rfc6376#section-8.2> 8.2 "Misuse of Body Length Limits ("l=" Tag)" says to "To avoid this attack, Signers should be extremely wary of using this tag..." Yet here we are where it's being used despite the vulnerability being known back 2011. We need a new authentication technique where such obvious footguns aren't possible. -Wei
On Sat, Jan 25, 2025 at 2:14 PM Michael Thomas <m...@mtcc.com> wrote: > > On 1/25/25 10:10 AM, Richard Clayton wrote: > > > There are additional needs. They are new. Or, at least, they were not > > > previously a priority. Since they were not needs when DKIM was > > developed, they > > > are not 'shortcomings'. > > > > they may not have been perceived to be shortcomings then -- they are > > now, which is why a number of people wish to improve things for the > > people whose email they handle > > Fwiw, mailing list traversal was always a shortcoming of DKIM from the > very beginning. That some people dismissed it at the time doesn't alter > the fact that it was -- and is -- a shortcoming. Our original intent at > Cisco was to address the internal spear-phishing problem for us, but > given Cisco's widespread use of mailing lists -- both internal and > external -- that made it a hard goal to achieve. z= and l= were an > attempt to be "good enough" on my part even though there was a lot of > hostility at the time (they actually worked pretty well in practice). > That's especially true of l= since the objection was that it was > "insecure", but any new mechanism which records what changes an > intermediary made has the exact same "insecurity" in that the message > will differ from the originating signature's signed canonical text whose > changes may or may not be benign. Frankly, that's up for the receiver to > figure out which I think they are capable given spam/scam filters, etc > and the reputation that you can assess from the intermediaries making > the mutations. I even wrote a patent app about that which I don't think > was issued probably because it was too obvious. > > Mike > > > _______________________________________________ > Ietf-dkim mailing list -- ietf-dkim@ietf.org > To unsubscribe send an email to ietf-dkim-le...@ietf.org >
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
