On 15/11/2025 4:21 am, Allen Robinson wrote:
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.
The method I propose is in lieu of many of the proposed changes that
would touch SMTP code directly, not in addition to them.
While draft-gondwana-dkim2-header does not change how the resulting SMTP
transactions would be processed, it does necessitate significant changes
in mail flow in order to create those transactions in the first place.
Even if more complex to implement, a solution that does not break
existing use cases or increase CPU, storage and network utilisation by
O(N), is worth considering.
I had considered adding a comment relating to intermediaries without
DKIM2 support, but I wanted to focus on feature parity with
draft-gondwana-dkim2-header as much as possible. That currently states
"... systems that accept email which has been outside the DKIM2
ecosystem MUST NOT add any further DKIM2 headers."
I believe same information would be preserved when re-entering a
DKIM2-capable system with either approach.
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.
I don't believe spaces are permitted in RCPT parameters. The syntax
(aside from bcc, which I agree should probably be consistent), is
compatible with DKIM-Signature header tags, where FWS is optional. I
used existing code to verify my examples.
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 DKIM2-Signature is necessary to link the recipient to the specific
email, so both should be used together when verifying the recipient.
Without doing so it would be possible to replay the recipient signature
with another email.
As the e-mail and recipients can be signed with a single call to the
filter, there is no reason to use a separate key.
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.
DKIM2RCTP is signed by the host that added the recipient, verifying
their intent to send to that recipient. Intermediaries do not re-sign this.
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.
I don't consider this to be particularly useful either. The information
is not available to filters when it needs to be and adding a DNS record
leaks information about email routing. It is for these reason I proposed
adding a lightweight stub to sign the next domain when sending. If it
were to be eliminated altogether, then any changes to outbound SMTP
would be limited to adding a DKIM2-Recipient header if the next server
doesn't support DKIM2. This should be considered 'easy' given senders
routinely have to make late decisions based on EHLO.
I do like the idea of having some sort of signing authority, but that's
to work around inflexible ESP requirements. That may be better addressed
by other means.
On the matter of crypto, I strongly favour removal of RSA altogether.
Another thought I had, which may be more palatable when addressing the
PQC issue, would be to mandate the use of Ed25519 for signing the
recipient, adding a one-time key in the DKIM2-Signature. That avoids any
need to increase the command line length and the public key used for
verification would always be signed by the 'secure' PQC DKIM2-Signature key.
Regards,
R. Latimer
Inveigle.net
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
