On Tue, Feb 4, 2025 at 4:28 PM Dave Crocker <dcroc...@bbiw.net> wrote:
> On 2/4/2025 4:20 PM, John Levine wrote: > > It appears that Dave Crocker <dcroc...@bbiw.net> <dcroc...@bbiw.net> said: > > If your above statement is true, then why is it necessary to do the > reversal? > > So you can tell if the earlier signatures in the chain were real. > > A DKIM signature is self-validating. > Unless its hashes are broken. Bron's motivation draft <https://datatracker.ietf.org/doc/draft-gondwana-dkim2-motivation/> describes a way to recover the hashes, including describing the reversing operation and the order that it's to be applied. The underlying technology for signing and verification of hashes uses DKIM much like ARC. > > Why doesn't one handler's taking responsibility eliminate the need to > worry about the predecessors. > > That's what ARC did, a chain of signatures with no way to tell whether > anything > but the most recent one actually matched the contents of the messages. We > tried > that and its acceptance has been underwhelming. > > There are many possible reasons for that. Is there data that points to a > specific adoption and use problem that the current one solves? If so, it > would be helpful to see it. If not, then this sounds like a guess, within > a very complicated problem and solution space. > > Anyhow, I took Wei at his comment. As he stated it, the utility of the > preceding signatures is not at all clear. > My first response was to directly answer your questions in the most straightforward way. Moreover each receiver will use this attribution information differently, and I just answered as how I see it. Sorry if it was not clear. > > It seems to me that a validated chain can be useful for developing the > reputations of all of the entities with signatures in the chain, not just > the most recent one. > > Can be is different from will be, especially since it also permits might > not be. An international standard requiring widespread implementation and > use is a rather expensive experimental sandbox. > > > Also, we know that most of the changes that mailing lists make are fairly > simple, so I can imagine filtering schemes that recognize changes that > lists usually do, so if it sees a message with list-like changes, it can > give more weight to the reputation of the earlier signers. IF it can't > evaluate the changes, it's no worse off than it is now. > > Hence my use of "Procrustean" since what you've described is an > environment that will penalize places doing otherwise legitimate changes > but not conforming to the fairly simple changes the filtering engines > expects (ie, demands.) > I commented <https://mailarchive.ietf.org/arch/msg/ietf-dkim/hohNna8Kh-igfUAHo2IjpSA3ooI/> not long ago that the WG ought to consider complex and simple changes. Bron's algebra draft <https://datatracker.ietf.org/doc/draft-gondwana-dkim2-modification-alegbra/> supports fairly general changes at the expense of diff overhead. I happen to agree with John that most changes are fairly simple and there's a lot of advantages in supporting the common case. But this is something that should be evaluated with operational data and better yet on the ground experience with an implementation as I would agree with what many have said that mutations can often be complex. -Wei
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
