As I read your message, I think you're giving a reason you don't think that draft-gondwana-dkim2-header-02 is ready to be published. I don't see what you wrote as a reason that draft-gondwana-dkim2-header-02 is not a good *starting point* for working group discussion (during which discussion you would make the arguments you put here).
Or perhaps I'm not understanding? Barry On Mon, Oct 13, 2025 at 7:09 PM Inveigle.net <[email protected]> wrote: > > On 14/10/2025 8:08 am, Murray Kucherawy via Datatracker wrote: > > Please reply to this message keeping [email protected] in copy by > > indicating > > whether you support or not the adoption of this draft as a WG document. > > Comments to motivate your preference are highly appreciated. > > I do NOT support adoption of draft-gondwana-dkim2-header-02. > > My objection relates to the use of the rt= tag, the rules surrounding > how multiple active headers are handled (including some seemingly > contradictory statements), the risk of data leakage and loss of freedom > of implementation. > > Without being a party to the side discussions that resulted in previous > revisions allowing multiple active headers, as I interpret it, this is > intended to allow a signer to insert one signed header for each intended > recipient that then MUST be removed by the server when it relays the > message. This addresses concerns I have expressed previously, from the > point of view of a sender, but it introduces other risks that can easily > be avoided. If this was not the intent, then this concern remains. > > Section 7.1 imposes a requirement on the creator/sender to ensure no > data leakage, however, DKIM implementations usually have no knowledge of > e-mail routing. Filters, where DKIM is usually implemented, also do not > have knowledge of their clients/hosts capabilities and if configured > incorrectly, could include rt= header variants that it expects would be > subsequently removed by the SMTP host (which it believes to be DKIM2 > capable) or at the next hop, but actually aren't. > > While the addition of an ESMTP DKIM2 option appears unavoidable given > the greater objectives of DKIM2 (independent of the header document), it > is undesirable to entrench DKIM2 requirements within SMTP itself in a > way that that would lead to loss of flexibility, including choice of > implementation. DKIM1 caters to a wide range of signing and verification > scenarios and it's critical we not sacrifice those, despite some > individuals being outright dismissive of certain valid use cases. > > Given the requirement for DKIM2 support to be negotiated and the > guarantees advertising this ESMTP option would mandate, there is no > barrier to moving the signature to the envelope en route, via RCPT TO. > There are, however, advantages in doing so. This relatively small change > would ensure the maximum extent of BCC disclosure would be no greater > than it currently is, even if systems were misconfigured. It would also > eliminate the requirement to split messages at the earliest opportunity > as BCC'd recipients and their associated hashes would never be seen by > any server other than that those to which it was intentionally sent. In > doing so, it also preserves existing use cases. > > The only point at which splitting messages would be required would be on > handover to systems that do not support DKIM2 or on delivery, at which > time a header would be added containing a hash that would be verifiable > using a key that was already used to sign the e-mail. As the e-mail > would only have a single recipient at that point, this would be > functionally equivalent to including only the active DKIM2-Signature > with a corresponding rh= hash. > > While I did mention this approach in an earlier e-mail on this list, it > did not elicit much discussion, although the need to retain > compatibility with RSA was suggested. While I favour removing RSA > altogether, the RSA case could be handled by simply including a hash of > the calculated signature instead of the signature itself. The hashing > algorithm need only be sufficient to guard against collisions, but for > simplicity, I'd suggest SHA-256 as that's what is mandated elsewhere. > > The resulting RCPT TO and header would look something like this... > > RCPT TO <[email protected]> > [email protected];s=selector;h=oTjChbUP05I+4PXR8wSHTpuy+q/uV9MrnCss8l+J3Js=;i=1 > DKIM2-Recipient: > [email protected];s=selector;h=oTjChbUP05I+4PXR8wSHTpuy+q/uV9MrnCss8l+J3Js=;i=1 > > Similar to the DKIM2-Signature header itself, this would be a signed > hash of the DKIM2-Signature (as identified by the s= and i= value) and > the RCTP TO/DKIM2-Recipient string as above, with an empty h= value > filled in after the value is calculated. > > I'm also uncertain how I am meant to lookup keys. In DKIM1, s= and d= > combine to give me this information, but d= is described in the document > as always matching the domain of the return-path, which shouldn't > change. Is the intent to combine this into s= (like ds= in revision 00)? > > 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]
