On 1/27/25 11:08 AM, Al Iverson wrote:
On Mon, Jan 27, 2025 at 12:55 PM Michael Thomas <m...@mtcc.com> wrote:

Sorry, no. From a security standpoint they are identical problems so if you're 
making an argument against l= then you are also making an argument against 
anything else that allows you to know how to reconstruct the original 
signature. The receiver in both cases needs to consider the mutations and 
whether they are acceptable and potentially consider it the light of who made 
those mutations and their reputation.

In fact, I would argue that a more complex mutation algebra would be even more 
dangerous than the simple minded l= which just allows appending content. For 
example, suppose it allowed in-body changes (eg, ostensibly for MIME changes), 
evil.com could add a hyperlink to text in the body of the original message:

<a href=evil.com>Click here for free money!</a>

which you can't do with l=.
Something doesn't compute here. Back when the concern around the L tag
hit the public consciousness in May 2024, I observed a fair amount of
mail hitting my spamtrap network with the L tag set up in a way where
I was able to grab messages and modify the body to change it to add
"evil" links just fine, and then inject the message, receive it, and
it passes DKIM. So either I don't understand, or you're wrong about
that. L was implemented in a way that didn't "just allow appending
content," it also effectively allows modifying content beyond byte X
with no corresponding failure in the DKIM signature checks.

The only way that would work is if the originator did something like l=0, which hopefully nobody does. If the l= contains the entire body as sent by the originator you wouldn't be able to do that.

That said, the complaints (overblown imo) about l= go back 20 years. It's hardly a new argument, and anything the supersedes it will have the same considerations.

Mike

_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

Reply via email to