On Tue, Apr 15, 2025 at 10:24 PM Dave Crocker <d...@dcrocker.net> 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. > One of the differences between RFCs 4871 and 6376 was that we backed off of providing a normative list of what you SHOULD sign, and went with a softer list of currently known fields you might consider, instead saying you really ought to be signing anything that impacts presentation to the user. The downside of this approach is, apparently, that some operators don't know which header fields those are. There was a nascent (don't know if it went anywhere) effort to construct a private BCP of sorts to answer that question for operators that felt they needed such guidance. The other issue is that over time, that list will change, so we (the original DKIM WG) opted to present the "flavor" of what should be signed rather than being prescriptive. If we include such a list explicitly here, whether it's an include list or an exclude list, we'll need to consider the need to update it from time to time. -MSK
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
