Richard,
Thanks for posting detailed commentary on basic points... inline...
On 9/17/2025 2:24 PM, Richard Clayton wrote:
DKIM1 (the current RFC) specifies on a per-email basis which header
fields should be signed. However, many email senders do not appreciate
that numerous header fields impact how an email is handled, displayed
and responded to -- and that if these are not signed then there is scope
for security problems to arise. This is a Bad Thing.
I don't recall hearing discussion of this serious problem here in the
IETF, never-mind from 'many' email senders.
Who are they? How can we vet your assertion?
Also: I'm not clear what you mean by "numerous header fields impact".
That sounds like a desire for fewer header fields, but I suspect you
don't mean that. So, please explain.
There are websites and blogs that proffer advice at to what should be
signed, but there is limited agreement in this advice.
DKIM intentionally did not specify which fields to sign, on the
expectation that the industry would develop some conventions about.
Also because DKIM was not intended to 'protect the integrity' of
messages, but to affix an identifier that ensured a clean message stream.
The current desire is for a using DKIM to serve a very different
purpose, which is a more classic "authentication and integrity"
assurance of the message.
That is a significantly more demanding functional requirement, having
nothing to do with the basic components of DKIM. It has to do with
conventions specifying what to sign and what a signature means. The
mechanics of the DKIM engine are unaffected by changing those
conventions. That is, it is a major change in use, not a change in
technology.
To pursue that seriously requires some pretty clear statements of threat
concerns, to guide choices of what to cover with the signature and what
not to. While there have been references to such discussions happening
elsewhere, they have not happened here.
And such a discussion needs to explore basic issues, before debating
specific choices.
There is a further problem with DKIM1 in that header fields may appear
more than once (even though RFC5322 might forbid this for many header
fields). As various people have described it is not uncommon for
different parts of a mail system to use different instances of these
duplicated fields, so that a verifier might check instance 1 but the
user will be shown instance 2 (or vice versa). This is Also Bad.
There have been references to this, over the years, but I don't recall
seeing documentation of it. Examples of this being a problem in actual
practice would be helpful.
Hence, many systems "oversign" by specifying a header field name more
than once -- signing the null second instance means that if an actual
second instance is added then DKIM1 verification will fail.
Indeed it will. But isn't that exactly the proper result? If not, why not?
These are issues even for some of the largest organisations out
there -- as just one example (of a great many) a household name
eCommerce website fails to sign the "Reply-To:" field -- because
they don't usually supply one.
How is that a demonstrated problem?
So best practice for DKIM1 is to have a rather long list of header
fields (combining all the various bits of advice)
Some documentation of the aggregate advice, and some IETF rough
consensus on that advice would be helpful. As in, essential.
and oversign every
header field that is actually present. If this actually done then
there's quite a lot of bytes being shifted around with every email...
Just to make sure I understand this point (and I recall your making it
before): you are concerned that explicitly listing all of the header
fields covered by the signature will add enough bits to messages to be a
burden for mail processing software?
And since I know you know what modern email header fields look like, in
the wild, I have to ask how this concern is credible, since the
incremental burden is in the noise.
if
not done (which is generally the case) then there are numerous
opportunities for bad people to mess with authenticated mail in
undetectable ways to the detriment of email recipients.
When the realm of threat is corruption of the message, then yes, there
needs to be diligent consideration of what to cover with the signature
and what not to, in order to have the appropriate end to end data integrity.
So in DKIM2 our first design decision was to get rid of over-signing by
specifying that if a header field is signed then all instances are
combined and signed. Assume hat is the case as we move on...
"then all instances are combined and signed" but it is not clear what
this means, that is different from current practice.
If there are two To: fields, then the current list of fields will
include to,to.
In concrete, technical terms, what are you proposing that is different:?
Then as we worked on the DKIM2 design we had to decide exactly which
header fields were to be signed. There are various possible approaches:
The extensive discussion that followed below this requires foundational
development of principles guiding what to protect and what not to.
Absent that, it is just a random walk through personal preferences.
It's not that any one person's preferences are likely to be bad or
wrong, but that individual variance makes the result incoherent.
Worse, whatever list is developed now will be inadequate eventually.
As soon as the desire is for comprehensive data integrity, then there
needs to be a plan for evolving the list comfortably over time, since
email use evolves.
The framework that you've been describing, here and earlier has three
characteristics:
1. Specifying fields required to be covered
2. Permitting signers to add more fields
3. Making the required set be implied rather than listed explicitly
Interestingly, 1 & 2 are already part of DKIM. So the issue here is
merely that you want 1 to have a (much) longer list.
And your argument for 3 has been to save bits, as surprising as that
seems. So while it produces no serious benefit, it:
* risks different signers or validators managing to use different
default lists -- because there is plenty of operational history with
that sort of thing happening, and
* it creates an artificial incompatibility with how DKIM currently
functions.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @[email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
