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.
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.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @dcrocker@mastodon.social
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
