On Tue, Apr 15, 2025 at 10:25 PM Dave Crocker <d...@dcrocker.net> wrote:
> On 4/15/2025 9:21 PM, Bron Gondwana wrote: > > Honestly, with the capacity to undo header changes from > dkim2-modification-algebra I would be more inclined to have the spec list > headers which MUST NOT be signed (probably just trace headers), and to list > additional headers to not sign, rather than additional headers to sign. > > I would also mention here than one thing we (or at least I) want to change > between DKIM and this new spec, is that every instance of any signed header > is signed, there's no "oversigning" where you have to list "Subject" twice > in the list to avoid somebody adding a second Subject header which displays > in some systems despite the first one being the one that's checked by the > signature verifier. > > > DKIM's model for what to include in the hash had, as I recall, a lot more > to do with what would be sufficient for 'attaching' the domain name to the > message, and I think, far less to do with protecting against modification > of the message. > > The current discussions appear fully in the camp of classic, crypto > 'protection' of the content. > +1 and with the modification algebra idea that allows for the recovery of prior valid signatures, knowing who, here meaning which domain, made the change. > Still, it would be extremely helpful to have a clear and detailed > statement of the threat model being applied and the justification for it. > That is, moving from theoretical threat concerns to real-world pragmatics > that justify the effort and ensure the benefit. > +1 I see the value in a threat model for the new specification, but to help us flesh out edge cases we might have missed. FWIW having been looking at our past bugs in this space to build our internal rationale, I believe that the new specification will already solve a rather important set of real world problems i.e. the ones mentioned in the draft-gondwana-dkim2-motivation <https://www.ietf.org/archive/id/draft-gondwana-dkim2-motivation-00.html> draft. -Wei
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
