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.
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. -Emanuel On Mon, Jan 27, 2025 at 11:27 AM Michael Thomas <m...@mtcc.com> wrote: > > On 1/27/25 11:19 AM, Al Iverson wrote: > > On Mon, Jan 27, 2025 at 1:14 PM Michael Thomas <m...@mtcc.com> > <m...@mtcc.com> 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 -- 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
