On 1/27/25 12:41 PM, Emanuel Schorsch wrote:
Michael, I agree with you that there's a security risk to allowing footer modifications. But I think Wei's point is critical, the difference between the l= vulnerability and the algebra vulnerability is that the algebra will require clear attribution of which party made the modification. That makes an enormous difference. Unlike l= you can now verify whether or not any 3rd party modifications were made, and choose to not trust the DKIM pass if modifications exist.
That's not entirely true: mutating intermediaries are more than welcome to resign the message they modify. That's always been the case. By resigning it, they are taking responsibility for the changes. That allows receivers to use the intermediary's reputation as part of the filtering mechanism.
I agree that the intermediary annotating what they did to the message is a better idea, but it's six of one, half dozen of the other on the security front. If this gets uptake, I think that would be good thing, and better than z= and l= which were the only things likely to be deployed at the time. But trashing l= also trashes any other annotating scheme's security as well, so tread lightly, IMO. I've always thought that the risks were overblown, and I think that's the stance that people should take for any new incarnation of figuring out what changed from the original sender.
I personally, don't think that the algebra is enough to treat it as a DKIM pass, and think it should be handled in a nuanced way in a third category, neither DKIM pass nor fail. But I recognize that it's valuable to have the attribution of what change was made and it then gives different receivers flexibility on what policies/approaches they want to have. If you're a more conservative receiver then you can easily decide to treat any 3rd party modifications as a DKIM fail. But you'll still be in a better situation than with l= where you can't even tell if a modification was made.
Pass/fail, etc are not especially important, IMO. What is important is whether the receiver/filter has enough reliable information to make intelligent filtering decisions.
Mike
-Emanuel On Mon, Jan 27, 2025 at 11:27 AM Michael Thomas <[email protected]> wrote: On 1/27/25 11:19 AM, Al Iverson wrote:On Mon, Jan 27, 2025 at 1:14 PM Michael Thomas<[email protected]> <mailto:[email protected]> wrote: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.Yep. In what I've observed, L=1. I'm glad you now agree that it's possible!Only if the sender is being exceedingly stupid. All that proves is that there are stupid deployments. Hardly something to judge all by.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."Hardly new" doesn't seem to be a suitable reason to leave it be. "Anything new will have the same problem" is a heck of an assumption, and not one I agree with.Assuming any new scheme allows for arbitrary body changes, it's the same security risk, and actually makes it more difficult to evaluate. Mike _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
