[Ietf-dkim] Re: Manipulation of signed messages
On Thu, May 30, 2024 at 9:13 AM Alessandro Vesely wrote: > z= saves all fields, which would be too much in most cases. Moreover, > doing so > suggests treating all fields as a whole, rather than dealing with each > one's > peculiarity. > That's not what the RFC says. Of course, if an Original- field is tampered with the original signature > won't > verify after replacing it, just like if you altered z=. But then, > reverting > without cooperation is not the same as doing it with active opposition. > Why > would someone alter Original- fields? A mediator wanting to disrupt the > possibility to reverse had better removing the signature directly. > Space munging applied to all fields, for example, is enough to break this scheme. "z=", by contrast, is immune to such mutations, because it's encoded. -MSK ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: Manipulation of signed messages
On Thu 30/May/2024 15:27:51 +0200 Murray S. Kucherawy wrote: On Thu, May 30, 2024 at 3:30 AM Alessandro Vesely wrote: z= is a valuable tool for debugging and learning why signatures fail. For reversing purposes, instead, Original-* fields are preferable as they can be individually added and possibly signed also by different operators. Reversal must not blindly replace altered fields so as to force verification. It should check whether the applied changes meet per-field acceptance criteria. > I don't understand your "preferable" claim given that an Original-* field is subject to mutation just as any other field is. It's just as fragile as any other solution. At least with "z=", you're far more likely to get back an actual original. z= saves all fields, which would be too much in most cases. Moreover, doing so suggests treating all fields as a whole, rather than dealing with each one's peculiarity. Of course, if an Original- field is tampered with the original signature won't verify after replacing it, just like if you altered z=. But then, reverting without cooperation is not the same as doing it with active opposition. Why would someone alter Original- fields? A mediator wanting to disrupt the possibility to reverse had better removing the signature directly. Best Ale -- ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: Manipulation of signed messages
On Thu, May 30, 2024 at 3:30 AM Alessandro Vesely wrote: > z= is a valuable tool for debugging and learning why signatures fail. For > reversing purposes, instead, Original-* fields are preferable as they can > be > individually added and possibly signed also by different operators. > Reversal > must not blindly replace altered fields so as to force verification. It > should > check whether the applied changes meet per-field acceptance criteria. > I don't understand your "preferable" claim given that an Original-* field is subject to mutation just as any other field is. It's just as fragile as any other solution. At least with "z=", you're far more likely to get back an actual original. -MSK ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: Manipulation of signed messages
On Thu 30/May/2024 00:02:40 +0200 Murray S. Kucherawy wrote: "z=" has been around since RFC 4871. The "z=" tag, when used, typically contains an encoding of the entire original header. This could be used to recover a signature that was invalidated by a header field modification of some kind. Has anyone heard of a verifier actually doing so? OpenDKIM can do this. It won't then switch the result to a valid one, but it will at least tell you what change was made to the header that invalidated the signature so you can pass that information back to the signer if you wish. I thought this was a valuable thing to add at the time, but I don't think I've ever heard of anyone trying to extend it to change the validation result. z= is a valuable tool for debugging and learning why signatures fail. For reversing purposes, instead, Original-* fields are preferable as they can be individually added and possibly signed also by different operators. Reversal must not blindly replace altered fields so as to force verification. It should check whether the applied changes meet per-field acceptance criteria. Likewise for identifying the footer. To store the original body hash obviously is not an acceptable solution. All of that is meant to say that the idea of undoing mutations you're able to identify has existed for a while, at least in one implementation. However, since it hasn't been identified as an interesting capability in the intervening years, it would seem to support Barry's claim that a broken signature oughta just stay broken. There is a set of gentle changes that we learned to accept and treasure during decades of mailing list usage. However, that set, which we may call traditional, was never standardized. In addition, there are other kinds of community-distributed messages that might also be called mailing list, even though they don't follow that tradition. Thence some confusion. Rather than not interesting, the reversing capability has been identified as fragile and messy. Yet it is the only possible /unilateral/ remedy to From: munging, AFAICS. The latter, in turn, is the preferred unilateral remedy to DMARC. In this respect, it looks like we lost the ability to develop cooperative solutions. Best Ale -- ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
