On Tue 01/Apr/2025 19:45:10 +0200 Murray S. Kucherawy wrote:
On Tue, Apr 1, 2025 at 10:26 AM Alessandro Vesely <ves...@tana.it> wrote:
The resulting DKIM verifier is not semi-broken, it's DKIM2-tolerant. And
it's not just a library change, it's also the MTA interface.
First you said: "a DKIM1 verifier will be able to verify a DKIM2 signature,
limited to DKIM1 semantics", but I don't know what this means. I'm
assuming by "semantics" you mean DKIM2 presumably will have its own way of
interpreting or even developing the pass/fail result.
No, it's not so much the interpretation of pass/fail, which I think will be
expressed by policies anyway, but the checks you perform to achieve that
result. DKIM2 checks the envelope, for example, which DKIM1 does not. So
DKIM2 may fail on messages that DKIM1 passes. OTOH if the body hash doesn't
match DKIM1 fails and so does DKIM2.
I think what you're saying means we would need (or STD 76 would implicitly
impose) a mapping from DKIM2 semantics to DKIM semantics. If I have all
that right, I think we're saying that we probably don't want this, or at
least there are some undesirable failure modes in that direction, such as a
DKIM2 signature that should fail but DKIM passes it, or vice versa.
Such a map would certainly be helpful. I can't think of a case where DKIM
fails but DKIM2 passes, either if there are separate signatures or a single
DKIM2 signature which DKIM1 interprets as it can. DKIM2 does more checks than
DKIM1. That map ought to be a list of cases that DKIM1 passes but DKIM2 blocks.
Then you said: "a DKIM1 verifier could be updated to handle DKIM2
signatures —if DKIM2 signatures were specified with compatibility in mind",
but if they're compatible (your premise), what update is needed?
They are tiny modifications, from a coder POV. For example, assume c= is
relaxed rather than simple if none is given.
Then "The verifier might not be fully DKIM2 compliant, perhaps because the
MTA interface does not support it or for some other reason." To me those
are mutually exclusive; a DKIM verifier that doesn't have access to the
envelope, say, can't possibly verify a DKIM2 signature. That part, at
least, is harmless, except when you consider that the industry does,
contrary to our advice, sometimes degrade the value of a message bearing a
failed signature.
That's the way it goes. From an operator's POV, if there is a DKIM2 library
for your platform, you go and install it, so you can accept or reject based on
DKIM2 signatures. If there's no such library yet, then you stick with DKIM1
and SPF. Meanwhile, those who have a DKIM2 module will sign both ways. If at
at some point most DKIM1 filters can at least make sense of DKIM2 signatures,
the latter operators can retire their DKIM1 modules and sign DKIM2.
If I'm still misunderstanding, then you're going to have to make this
concrete with an example.
The example you made is perfect: an MTA where filters cannot access the
envelope can have only "DKIM2-tolerant" filters. On signing new messages, they
may even be able to produce DKIM2 signatures.
At that point, the transition will have taken place. The alternative, keeping
DKIM1 strictly separate from DKIM2 and perpetuating the dual signature, seems
less attractive to me.
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
