Perhaps it’s just me... but I think it’d be great if we could focus on the question of the charter before diving into the solution so that we can unlock the coveted “Work Group Status” in order to leap off the deep end.
Basically, I’m concerned there are two camps currently on this thread: those discussing the charter, and those discussing the solution (or why the proposed solution is pure silliness)... and I think we need to lock the first before moving onto the second. - Trent From: Emanuel Schorsch <emschor...@gmail.com> Date: Monday, January 27, 2025 at 1:42 PM To: Michael Thomas <m...@mtcc.com> Cc: ietf-dkim@ietf.org <ietf-dkim@ietf.org> Subject: [Ietf-dkim] Re: Charter #4? 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 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<mailto: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><mailto: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<mailto:ietf-dkim@ietf.org> To unsubscribe send an email to ietf-dkim-le...@ietf.org<mailto:ietf-dkim-le...@ietf.org>
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
