On Fri, Oct 24, 2025, at 22:09, Inveigle.net wrote: > 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.
So long as you can extend the list of headers, and specify arbitrary strings for things like selectors, I don't buy this argument. > 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. I do think this is a legitimate are of discussion and I won't die on this hill, I'd be happy with a more DKIM1 compatible limited set of signed headers. > 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. This is definitely something I would require. And MailVersion would need to describe how to undo any changes to those headers along with a new signature. > 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. I'm happy to discuss this at the next meeting and continue to debate it on the list. I agree that a list of "you MUST sign this list of headers to be considered a reasonable actor in 2025" is enough. > == 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. I agree with this but it also brings the hugest benefits! Dave's proposal to decouple things enough that one or the other still gives benefits is good for the upgrade path; and that's what I've done with the latest MailVersion proposal. If you DON'T require it, then you wind up with something a lot closer to ARC, with the same failure modes that ARC currently has in production usage. > 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. I disagree. Particularly with header modifications, the way these systems have adapted is to do exactly the dkim.fail nonsense that even this email from you included! > 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. This is again the "sign all headers" argument above. Let's combine those as "arguments against signing all headers" and address MailVersion within that context. > 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. I don't know how what you mean here by "increasing confidence in message content". Message content is what it is, and the receiving system decides where it's good. If it ISN'T GOOD, then the receiving system has to try to figure out who to blame. It's a lot harder to forward arbitrary mail if you might wind up being blamed. That's the issue ARC is hitting right now, and unless you propose another way to figure out which system is accountable for message content, running a forwarding service or mailing list will continue to be plagued by the fact that the system becomes accountable for the entire content if makes even a minor modification to add unsubscribe links in the body, or changes the subject. > 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. I disagree with this characterisation. End-to-end tracking will help but bad actors can still get their hands on a copy and replay back into big domains like gmail as if they were an intermediate hop. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
