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]
