On 1/12/2025 2:44 pm, Richard Clayton wrote:
In message <[email protected]>,
Inveigle.net <[email protected]> writes
As discussed briefly at IETF-124, I have created an I-D describing an alternate
method for signing DKIM2 recipients and the next domain.
My apologies for responding to this so slowly, I wanted time to think
about whether the proposal had any merit after all ...
Thank you. I appreciate you taking the time to provide a considered
response.
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.
OK ... so as I understand it, instead of a sender placing the "RCPT-TO"
value into a DKIM2 signature (where it will be cryptographically signed
and passed along with the message to the eventual destination) instead
you cryptographically link the RCPT TO with the message -- so that the
receiving system can check that it was meant for them.
Correct.
Thereafter, when there is forwarding the cryptographic information is
transferred into a DKIM2-Recipient header -- which is intended to allow
replay detection and also to allow email to pass via non-DKIM2
forwarders...
Yes, although I realised the draft implies this would always occur
during delivery or handover to systems not advertising DKIM2 support. It
is not my intention to preclude this information from being transferred
to headers at any time should this be necessary. E.g. If an
implementation is not able to insert a header after determining the
capabilities of the next host, it would be valid to do this prior to
queuing.
Nothing would prevent an implementation from generating, signing and
queuing multiple messages as you describe below.
So far as I can see the only advantage to this scheme is that it means
that a sender who believes that there is a problem if multiple
recipients of the same message learn of each other's existence. This
does seem to be an edge case and the other drafts (which you will find
my name on) can handle this by such a sensitive sender generating
multiple messages (each with a single recipient).
While I consider it important to not unnecessarily disclose the
existence of BCC recipients, this is not the primary motivation, which
is to preserve existing use cases and optimisations.
The problem with the 'simple' solution is it is deceptively simple.
A quick split achieves the basic DKIM2 objectives, albeit with an O(N)
penalty in signing, storage and data use. Even if one were to accept
this and overlook the additional issues it creates, there remains one
giant caveat - neither SMTP nor DKIM require existing implementations to
have any header parsing or message splitting capabilities within their
SMTP code.
The need to add complex header parsing and queuing to SMTP
implementations specifically to support DKIM2, means the simple approach
is not universally simple.
Leaving the Next Domain aside, as it's a separate concept, the extent of
my proposed DKIM2RCPT extension is nothing more than storing and
forwarding a simple string and adding a header. It's not a
protocol-level change that requires major architectural work, it keeps
the vast majority of DKIM functionality encapsulated where it should be,
within filters (or discrete code for monolithic implementations), and
reduces the involvement of SMTP to nothing more than trivial string
manipulation.
Because the header parsing would be carried out by the original DKIM2
filter that signed the recipient, the extent of logic required within
SMTP to make subsequent decisions on BCC delivery could be as simple as...
if(strstr(dkim2rcpt, "bcc=1"))
In practice, you would break apart the string and use the tag value, but
that is still significantly less work (orders of magnitude less), than
adding header parsing logic into a wide range of SMTP implementations
that presently have no need for it. Further, because it defers splitting
until a point in time at which it becomes necessary or an implementation
decides to do so as a matter of course, the extent to which software
needs to be modified is greatly reduced.
It requires a moderate amount of work in a relatively small number of
products, while requiring only minor changes to a much wider, unknown
number of systems that vary greatly in implementation and capability -
all of which operate in a way that is explicitly permitted by the
current DKIM specification.
Since the scheme requires a ESMTP extension, changes to buffer lengths
in MTAs and is pretty complex. In particular, it moves code that would
otherwise be in a library that created email to go into a queue, into
the heart of the SMTP protocol engine. As such I don't think we should
consider this further.
Allen raised the issue of PQC algorithms. Based on that and subsequent
discussions with people off the list, I favour including a single-use
key in the DKIM2-Signature. That would give the recipient key a fixed
length of 88 bytes (assuming Ed25519 was the only algorithm used) and
eliminate the need to increase this line limit.
In summary, the benefits of using an extension are numerous...
- Signing is fast - O(1), with a small overhead for recipient signing
during the initial sign only.
- DKIM2 filters only need to be called once, as is the case with DKIM.
- Storage requirements remain O(1).
- Network utilisation is O(1) for very common on-premises setups that
only forward, often over slower Internet connections with low or no CIR.
- BCC recipients never need to be split from other recipients on the
same domain if DKIM2 is available end-to-end.
- Client-side signing remains possible.
- Almost no additional logic is required within SMTP code specifically.
Regards,
R. Latimer
Inveigle.net
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
