To avoid a lengthy e-mail, I have split my concerns regarding
draft-gondwana-dkim2-header-x into two e-mails focusing on specific
design issues.
Herein, I discuss issues with header signing and change tracking. While
the draft that has been adopted does not directly address the specifics
of how these would be implemented, it does make provisions for both. No
presumption should be made that any technical challenges necessarily can
or even should be overcome in pursuing their realisation.
== Pragmatic Header Signing
I agree with simplifying the e-mail header list, provided provisions
remain for adding additional headers. I am, however, unconvinced by any
of the discussion I have seen on the matter of what headers should be
signed or the methodology.
There is, mathematically, no reason to sign any headers other than those
that may be used to mislead a recipient or cause them or an agent to
perform an unintended action. There is no need to over-think this and
sign more than is necessary. There has never been a collision found with
SHA256, and even if it's theoretically possible to create a collision
within the headers, it is computationally unfeasible to do so.
If you take the approach of simply signing everything, you potentially
make it easier to engineer a collision should a vulnerability in SHA256
be discovered, as you are no longer bound by the constraints imposed by
a relatively small set of headers.
The emphasis therefore should be on signing the relatively short list of
headers that are displayed to recipients and the few additional headers,
such as List-Unsubscribe, which have genuine potential for exploitation,
not merely theoretical (E.g. MIME-Version). The basic list of
client-facing headers has been largely unchanged for decades and is
unlikely to change significantly going forward. In the rare circumstance
that another significant header is added (like List-Unsubscribe), then
it should simply be documented as best practice for inclusion as an
additional header. With DKIM2 signing at each step, it is likely the
immediate upstream MTA would sign the header and provide a degree of
certainty around its legitimacy even if the original signer did not do so.
A trivial change to DKIM2 requirements would be to require signing of
all headers signed at the previous step in addition to any new headers
the signer wishes to add. This ensures any header considered significant
by any party continues to be signed throughout the delivery process.
Retaining support for specifying additional headers caters for headers
with specific security implications (e.g. MMHS). Any organisation
operating such systems would be subject to additional regulatory
requirements, policies and likely auditing which would ensure such
headers are correctly signed. It makes little sense for IETF to define
what these headers are when they are not the authoritative governing body.
So yes, simplify, but do so sensibly. With reference to the stated
motivations for DKIM2 published in 2024, the intention was to enforce
uniqueness of a simplified list of headers. My views are in line with
the original motivation, not the excessively complicated and highly
error prone proposal it has become.
== Change Tracking
The ability to track changes is one of the underlying motivations for
DKIM2, however, it is an idea that brings with it significant
challenges. In my opinion, this feature poses the single biggest risk to
the adoption of DKIM2 and the realisation of its other benefits.
The only justification provided for implementing change tracking at all
is to handle the case where e-mail forwarders and mailing lists make
minimal changes to messages. These services have already adapted to the
requirements of SPF and DKIM. There simply isn't substantive problem to
address.
If that was the extent of the proposal and signing changes was limited
in scope to specialist software that could, in isolation, make minor
changes to the e-mail content, ensure those changes were correctly
signed, and flag those changes in the DKIM2-Signature, then the proposal
is theoretically workable. Such requirements, however, are more onerous
than the workarounds already implemented, so it's questionable if there
is any real-world benefit even in those cases.
As it stands, however, the scope is not limited. The proposal to sign
all headers requires that DKIM2 be in a position to observe all changes
to e-mails, including those made by third-party filters or scripts,
across the entire SMTP infrastructure and potentially beyond depending
on implementation requirements. In addition to being inefficient, error
prone and highly susceptible to configuration errors, this would
preclude the introduction of a more fit for purpose change tracking
system, developed with more objective goals in mind, should there be a
demonstrable need to pursue such a feature in the future.
A recurring theme in the motivation and draft documents is the idea that
change tracking can help establish trust and inform policy. DKIM should,
however, be strengthened by increasing confidence in message content,
not weakened by introducing fuzziness and empowering receivers to make
subjective judgments about acceptable modifications.
Real trust comes from:
* End-to-end tracking of MAIL FROM and RCPT TO (via the DKIM2 ESMTP
extension)
* Signing a well-defined, security-relevant set of headers
* Stricter replay protection
* Adding a verifiable feedback mechanism
These are concrete, actionable improvements. Change tracking, as
currently proposed, is not.
Regards,
R. Latimer
Inveigle.net
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
