Thanks for writing this up in detail. Overall, this approach seems like it may be workable, though there is some added complexity.
I have some concern about this requiring changes in the SMTP processing layer in addition to all of the other changes that have been proposed. The previous documents did limit SMTP transactions to a subset of what's allowable by requiring transaction splitting in some cases (ex. Bcc) but did not change how the resulting SMTP transactions would be processed. A concrete example of my concern is an email going from a DKIM2-authoring system, through a MTA that doesn't change anything about the envelope or message, to a DKIM2-aware receiving system. In the existing proposals, the MTA in the middle would not necessarily need to know anything about DKIM2 and can continue operating as it does today. This proposal would require awareness of DKIM2 in all of those systems. Technical notes for the text: The extension's maximum command length will need to be significantly larger to account for PQC signatures. How much longer will depend on what algorithms are chosen. I don't think there has been any thought given to PQC algorithms in the WG yet other than to say that we should build the protocol to support other algorithms. The increased signature length isn't very concerning when being transmitted in a header field but it might be in this context. DKIM2RCPT should use tag=value syntax, even for fields like bcc that only have one meaningful value. This makes parsing easier to implement. Ideally, this would have the same syntax as DKIM2-Signature so only one parser is needed. The s= tag in DKIM2RCPT is a little awkward. A verifier can't do anything with the recipient signature in isolation. The verifier needs to find the corresponding DKIM2-Signature for hashing, and it can't even start key lookups early because the d= and a= values come from the DKIM2-Signature too. Using the same key seems reasonable here, but if it's not then this will need a d= and a= here as well. The i= tag in DKIM2RCPT feels potentially unnecessary. The signature should always be associated with the topmost DKIM2-Signature, and so the hashed content already contains the i= value. I can't think of a legitimate flow in which a system is sending a message with N signatures and associating the recipient signature with an earlier signature. The NextDomain stuff doesn't seem useful to me. It made sense in your earlier proposal when you were trying to dictate that the recipient signature always use Ed25519 for size reasons, but you made it possible to use RSA signatures in this iteration. If we were to keep this mechanism, I think I'd prefer it to be included in the DKIM2-Signature instead of being signed separately, so that it can't be stripped off without invalidating the signature. On Thu, Nov 13, 2025 at 2:08 PM Inveigle.net <cs= [email protected]> wrote: > As discussed briefly at IETF-124, I have created an I-D describing an > alternate method for signing DKIM2 recipients and the next domain. This > method makes use of the DKIM2 ESMTP extension to pass a recipient > signature through the SMTP session and places the next domain > information in a separate, independently signed header. > > Name: draft-latimer-dkim2-rcpt-nd-signing > Revision: 00 > Title: DKIM2 Recipient and Next Domain Signing > Date: 2025-11-13 > Group: Individual Submission > Pages: 12 > URL: > https://www.ietf.org/archive/id/draft-latimer-dkim2-rcpt-nd-signing-00.txt > Status: > https://datatracker.ietf.org/doc/draft-latimer-dkim2-rcpt-nd-signing/ > HTML: > https://www.ietf.org/archive/id/draft-latimer-dkim2-rcpt-nd-signing-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-latimer-dkim2-rcpt-nd-signing > > The objectives are to improve compatibility with existing DKIM use cases > and ensure that DKIM2 can implemented to the maximum extent possible > within the scope of filters, while limiting the amount of DKIM2-specific > logic being added to SMTP itself. It also offers significant performance > benefits in terms of both routing and signing efficiency, while reducing > the number of DNS lookups required compared to alternative approaches. > > This implementation requires filters to be able to edit the RCPT > parameters for recipients. Using existing Milter v8 protocol > functionality, this could be implemented by combining SMFIR_DELRCPT and > SMFIR_ADDRCPT_PAR. > > There is one caveat, however. Currently, Postfix does not fully > implement SMFIR_ADDRCPT_PAR and does not add parameters to added > recipients. The notes from when this was implemented indicate the > functionality would "require ESMTP command-line parsing in the cleanup > server". As other approaches would require more extensive DKIM2-aware > header parsing to be added, I don't consider this alone to be a > significant barrier to implementation. > > There is a valid concern around filter performance if the filter is run > during message delivery. While the decision of when to run the filter is > up to each implementation, the signing of individual recipients with a > signature derived from the DKIM2-Signature is significantly faster than > signing the same email multiple times and generating a new signature for > each recipient. > > In my quick tests, signing an email with a 40MB attachment addressed to > 100 recipients took 33% longer than signing for a single recipient, with > further optimisations possible. This is negligible overhead compared to > signing multiple instances of an email and as this approach would > typically only require each intended recipient to be signed once, this > additional overhead is eliminated from subsequent hops. > > While the specifics weren't discussed during the meeting, I have since > refined my proposal to have the signer explicitly declare BCC > recipients. This allows SMTP implementations to make routing decisions > without having to implement their own header parsing logic. > > Shortly before the meeting, Wei mentioned the potential for pp= to be > used to delegate signing to a platform and ease migration to Ed25519. I > had previously highlighted the benefits of explicitly delegating signing > authority, so since there is some support for that idea I have also > incorporated this into the DKIM2-NextDomain header. > > An explicit signing approval allows an ESP which currently manages user > keys to sign the original approval using an RSA key, then re-sign the > email and recipients using their own Ed25519 keys. > > Many users choose to route email through third parties out of necessity. > Surrendering control over keys that can sign on behalf of their domain > is a requirement for using many such services. Adding a delegated > signing authority allows users to retain control of their keys while > still permitting an ESP to make necessary 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]
