On Tue 22/Apr/2025 17:17:34 +0200 Murray S. Kucherawy wrote:
On Tue, Apr 22, 2025 at 11:12 AM Alessandro Vesely <[email protected]> wrote:
On Tue 22/Apr/2025 16:49:29 +0200 Murray S. Kucherawy wrote:
On Tue, Apr 22, 2025 at 4:56 AM Alessandro Vesely <[email protected]> wrote:
On Tue 15/Apr/2025 21:21:58 +0200 Bron Gondwana wrote:
So I'm very interested in a discussion of *"should we have an exclude-list
rather than an include-list of signed headers?"*
Don't sign MIME-Version: especially if it has comments.
RFC 4871 expressly listed that as one that SHOULD be signed. We softened
this in RFC 6376 to be basically a debate about whether MIME-Version (among
others) represents "core" content. I have always thought of anything that
impacts what the user will eventually see as "core" content that DKIM
should be covering.
So why would we not sign MIME-Version, given that it's key to
interpretation and rendering of the message?
I was going to add Content-Type: as well, but this is controversial,
because sometimes it is necessary. These are "technical" header fields
that are best left to machines. Signing them reduces the resilience of a
signature.>
So I could change a Content-Type field by adding/changing/removing
semantically important parameters, and you'd be OK with that?
A malicious transform could turn the message into a multipart, or wrap the
original multipart into something else. However, if it doesn't also modify the
body, it will have no payload.
If a mime-wrap operation was declared, in the guided transformation reversal
scenario I've been hinting at, the verifier will check the original text
remains prominent in the first place and that the added part consist of a few
text/plain lines.
Signing the Content-Type: is really only necessary if the original signature
had l=, which everyone advises against.
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
