Lots to unpack here. Apologies if I missed something. On Thu, Sep 4, 2025 at 4:44 AM Inveigle.net <cs= [email protected]> wrote:
> It is very clear from discussions on this list that the proposed DKIM2 > standard is considered by many to be revolutionary, not evolutionary as > it should be. As a developer, I immediately identified areas which I > consider unworkable based on how I currently use and deploy DKIM1. These > changes give rise to concerns around e-mail reliability, the ability for > DKIM2 to succeed as a standard and critically, the ongoing ability to > cryptographically sign e-mails under varied use cases. > > I am posting this so I can get some feedback on what has previously been > discussed and discounted, and hopefully gain insight into the direction > DKIM2 is heading, while also proposing what I consider to be a pragmatic > way forward. There is a lot of information in the mailing list archives, > however, I'm sure you'll all appreciate that it's not the easiest format > for someone, especially someone just discovering the DKIM2 proposal, to > navigate and interpret. I can, however, comment on the shortcomings I > can see in the proposed standard. > > I see the proposed changes, for which there clearly are strong > proponents, as a step too far. It is my view that the objectives of > DKIM2 should be reined in, covering as many of the bases as possible, > but without significant changes to existing implementations, breaking > historic mail flow, or risking some users being unable to move beyond > DKIM1 due to technical requirements. > I strongly suspect that limiting DKIM2's design space only to things that are easily adoptable for every single mail flow would look almost identical to DKIM, and not solve many of the problems that the WG is attempting to solve at this time. In particular, mail flows that are dependent on the same features that are used for abusive/malicious mail will be affected. Does this mean there will be flows that need significant rework to adopt DKIM2? Yes. Are there going to be systems that never adopt DKIM2? Almost certainly, as there are still systems out there that haven't even adopted DKIM. > The main issue I see, as a sender, is the DKIM-replay mitigation. I > agree with making the t= tag a requirement. It's something I use in my > own implementation and I don't permit users to turn off. The proposed > rt= tag, however, necessitates a breaking change in e-mail flow as a > separate signed e-mail must be created for every BCC recipient, which > isn't always practical or desirable. This could lead to implementations > being stuck using DKIM1, which is fine so long as DKIM1 remains a first > class citizen. There is, however, no guarantee certain providers won't > at some point in the future make arbitrary decisions regarding its > acceptability, despite it remaining entirely fit for purpose. > I believe I heard that there's an imminent update to either 5321 or 5322 that suggests sending BCC'd recipients separately, independent of what is being proposed here. > > I believe that the similar verification can be achieved through > non-breaking changes if the proposed ESMTP DKIM2 syntax is simply > extended to include a signed hash for each recipient. Any upstream > server supporting DKIM2 would pass this along to upstream servers and > the receiving server would be able to verify the recipient was an > intended recipient. This value would then be added to the e-mail prior > to delivery into the inbox, preserving the ability to perform > client-side verification. This doesn't fully address handover to > non-DKIM2 servers, but a simplified implementation would see faster > adoption of DKIM2 and realisation of the benefits sooner. > Including the addresses of all BCC'd recipients in the signature header field is obviously bad for privacy reasons. Including a hash is marginally better. However, a list of hashes still allows recipients to guess that the email was BCC'd somewhere (more signed recipients than would be expected based on To/Cc fields). A recipient could also make educated guesses as to which addresses might have been BCC'd and check them against the included hashes. Or for a sufficiently small local part namespace, they could simply bruteforce hash every possible address. > > The hash would only need to include the e-mail address and original > DKIM-Selector header, signed using the same selector key as the header, > rather than being a component of the header itself. Such signing within > the constraints of RCPT TO is feasible if we take the opportunity to > phase out RSA signatures as we deploy DKIM2. The proposal already makes > Ed25519 a requirement for verifiers, so that isn't an unrealistic > stretch. I believe the barriers to an Ed25519 implementation have been > gone for some time. My own implementation was delayed while I waited for > LibreSSL to add support, but that development was completed more than > two years ago. > Deprecating RSA has non-technical barriers. For service providers operating at scale, it is difficult (verging on impossible) to convince every customer to publish new public keys. This is the primary motivation for supporting RSA in DKIM2 at all. > > The RCPT TO approach would require very minor changes to filtering > protocols, allowing the extra parameters to be generated and observed by > filters. These enhancements would also bring potential benefits to other > filters through their being able to make use of parameters passed in > with RCPT TO. Importantly, it keeps much of the DKIM2-specific logic out > of the initial SMTP exchange, caters to all existing use cases, allows > flexibility of implementation and does not alter e-mail flow. Batched > deliveries for common recipients on a single server could proceed as > usual, with no special handling. > Ok, I guess this is what you were referring to a couple paragraphs above. This is an interesting idea that would reduce the information leakage between recipients. DKIM2 would probably still need to have the receiving domain listed in the signature to allow for verification that the message is being passed along by the ADMD that received it. I think it is only workable if it can be made to work with RSA signatures though. > > As current DKIM implementations vary in their placement of signatures > (even my own use varies depending if I am generating a signed e-mail or > simply signing), this should not be relied upon, with the proposed > sequence number (i=) for DKIM2 instead being used to determine which key > to apply (i=0) in the absence of a signature with a specific domain > match. If the first key fails, other intermediary keys that signed the > e-mail could be used to determine if a new RCPT TO signature is > acceptable, however, I consider the objective of supporting privacy > forwarding to be outside the scope of DKIM - DKIM is intended to ensure > e-mail integrity, and from the point of view of the sender, a forwarded > recipient is not where they sent the e-mail to. > > As a side note, the 'correct' handling of forwarded e-mail in my view > should be to encapsulate the whole e-mail in a specifically designated > MIME container. From that point, it would be considered a completely > separate e-mail and verification would be based on the trust of the > forwarder, with the original e-mail remaining entirely intact for > subsequent verification. At the end of the day, the only question asked > by the receiver should be, "Do I trust the sender?" > The wording here is a little ambiguous. I think in the case of A sending to B, and B forwarding to C, C may be interested in evaluating both the originator (A) and the forwarder (B). > > The reason for the note above is because in my view the current proposal > looks at trust from completely the wrong perspective. Being able to > calculate changes and determine when those changes occurred is > effectively the opposite of what DKIM set out to do, which was to allow > the sender to claim ownership of messages and verify their authenticity. > Being able to determine who injected bad content is only useful if you > know the bad content is there. Trust is not knowing how an e-mail has > changed, it's about knowing if any changes were approved. The trust for > upstream modifications must therefore be at the direction of the sender, > not determined by the receiver, especially not if the changes are hidden > within the SMTP infrastructure itself. DKIM has been viewed and > implemented almost exclusively as if it were only a necessity for > delivery, despite its utility across the entire e-mail infrastructure. I > want to see that change and DKIM be brought to the foreground. > First, I believe distinguishing "good" changes from "bad' changes is certainly out of scope for DKIM2. I don't think it's possible to come up with a workable definition for what types of changes are inherently good or bad. Having reliable information about the changes that were made and the systems that made them will likely be useful for higher-level systems that are making these determinations. Modifications can happen on receive-side infrastructure. This mailing list, for example, appends a couple links at the bottom of all messages. Modification tracking would allow a downstream receiving system to see that most of the message was signed by you, and the footer text was added by ietf.org. > Despite the IETF mailing list itself clearly being antiquated, my view > is that mailing list issues are 20 years past being relevant. I > wholeheartedly agree with removal of the l= tag, which could be used to > accommodate minor additions that may be made by mailing list software, > but all modern mailing list software should be constructing and signing > a complete new e-mail and sending that to individual recipients. Current > industry guidelines for unsubscribe links etc., all suggest they should > be doing so, so let's not perpetuate the myth that mailing lists need > some sort of special treatment. > > Editing based on policy is still relevant, as company policies still > often mandate the addition of disclaimers. Often, these are signed after > alterations are made, making changes a non-issue, but assuming they are > not, such changes, in my view, would be best served by establishing > explicit trust between the sender and upstream services. > Changes performed within an ADMD should not need any special handling at all. The trust relationship would be expressed by the mutating system having the ability to sign on behalf of the domain they are performing mutations on behalf of, or being positioned somewhere before signing happens. > > This could be in the form of another header, giving explicit approval > for a named upstream domain to make changes and potentially limiting the > scope of these changes either to the immediate upstream domain or a > service trusted by them. If changes are made, the e-mail would be signed > again and starting with the original key, that and any subsequent keys > could be used to verify the server was permitted to make these changes > by verifying the chain of signed headers granting such permission and > testing the upstream signing policy at each step. > > Granting change permissions would also mean intermediary services don't > need to be DKIM2 aware at all, allowing a smoother transition to the new > standard. These servers could even be DKIM1 hosts which routinely sign > and edit messages. Their changes would be trusted because the sender > said they can be. There are a large number of marketing services out > there which quite frankly shouldn't be holding the keys to their user's > domains. These services require control over keys for a domain because > they need to alter links and insert tracking etc., but would pass DKIM > checks using their own key if the ability to grant permission for > changes were to be added to the spec. Users would still need to setup a > DKIM key (which in most cases they would already have), but it would > remove the need for multiple CNAME records to be placed in DNS to > accommodate marketing providers and have the additional benefit of not > restricting those providers to switching between one or two > pre-determined selectors. This would greatly ease the ability to adopt > Ed25519 signatures ahead of a full DKIM1 to DKIM2 transition as it > wouldn't necessitate a hard switch over from one mechanism to another, > while at the same time improving security and allowing for longer > verification periods. > I don't think this aligns with how I've been told ESPs (Email Service Provider) work in general. From what I've been told, the typical setup is that they originate the email (including tracking pixels or whatever), and sign using both their customer's domain and the ESP's domain. > With regard to simplification, I suggest keeping the existing h= > arrangement and simply mandating additional headers. This is because > existing implementations must already calculate hashes in the order > presented and it creates an ambiguity for when over-signed headers > should be signed. The headers you most want to protect are also the ones > you probably want to over-sign, even if they are not meant to be > duplicated. While the proposed change would only represent a minor > change to code and should be easily implemented, other than reducing > header size by an insignificant amount, it otherwise appears to be > completely unnecessary. Likewise, I see no sense in hashing headers in > alphabetical order as it doesn't provide any protection against > reordering. It changes a critical step of verification, seemingly for > the sake of change. Keep the changes simple and a DKIM1 verifier would > still be able to verify a DKIM2 signature without any modifications, by > simply by ignoring unknown tags. What does the current RFC say about > unknown tags? Ignore them! Such compatibility also necessitates no > change to the existing canonicalisation default of simple/simple. > h=: I tend to agree that the value of this isn't quite as clear as some of the other changes being proposed. One motivating factor for signing a fixed list, or signing everything, is that it makes it harder for signers to inadvertently do something that opens them up to replay-with-modification style attacks, but we're already hoping that replay to other recipients won't be possible under DKIM2. Canonicalization: Having multiple methods for body canonicalization complicates the change tracking feature. For historical reasons that have likely been forgotten, the vast majority of mail uses relaxed/relaxed, so that's why DKIM2 has that as the only method for both header and body canonicalization. I suspect a reasonable argument could be made that the only canonicalization method should be simple instead of relaxed. > > In summary, I see DKIM2 being v=2, with an updated list of required > headers, removal of the problematic l= tag, the removal of RSA and the > promotion of Ed25519, the ability to trust upstream domains and replay > protection provided by way of a signed DKIM2 hash added to RCPT TO and > compulsory t= tags. > > Keep in mind this e-mail is largely a continuous stream of thoughts with > some minor edits, so I won't have covered every point and there will be > details that need more consideration, but I believe such an > implementation would be a solid upgrade to DKIM, worthy of the v=2 > label, without introducing breaking changes. > > Regards, > R. Latimer > Inveigle.net > > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
