Hello Edmund,
Il 2026-10-27 14:07 Edmund Lodewijks ha scritto:
I was wondering what could be done to help make DKIM2 succeed in a
better way than
when Ed25519 was introduced for DKIM, which never really took off
Ed25519 is one case and ARC is the more worrying one, because ARC is
close to DKIM1 for all that it develops across hops, and it is
architecturally simpler than DKIM2. After seven years it has on the
order of ten thousand signing domains against roughly nine and a half
million DKIM1 key records, as reported in
draft-adams-arc-experiment-conclusion. It fell short because it was
awkward to implement, as the resulting software shows, and because the
complexity did not pay for itself.
The Ed25519 figures I posted here earlier say something more specific
than “transitions do not happen”. In 61815 DKIM signatures received at a
domain I operate, Ed25519 accounts for 40, which is 0.065 per cent. Over
the same period rsa-sha1 fell from 7.09 per cent in 2024 to 0.36 per
cent in 2026, so operators did migrate, and they migrated to rsa-sha256,
now at 99.46 per cent. The change that cost a configuration edit
happened. The change that cost a new key type and new code did not.
These figures deserve to be looked at with some realism.
My concern is that deploying a new authentication mechanism involves
more than support
in signing and receiving MTAs.
You are better placed than most to answer the part that decides it,
because you have implemented a DKIM2 milter in C yourself.
Every email authentication protocol that reached broad deployment was
implementable in a filter that is stateless per message and streaming.
The filter sees the envelope at the SMTP callbacks, then the header
fields, then the body, once and in order. Adding signed header fields
that describe what it has just seen fits that exactly.
If I do not want to rewrite half the world’s code, I am forced to make
two filters talk to each other, one ahead of a modifier and one behind
it, two instances that have to share storage across the content
pipeline. The plan published in the interoperability repository on 14
October does precisely that for unmodified Mailman: the inbound milter
writes the message as it arrived into a snapshot directory shared with
the outbound one, keyed by a token it inserts into the message, and the
outbound milter diffs against that snapshot. Signing and verification
stay stateless, it is recipe generation that needs the shared storage.
You will know better than I do what that costs in a milter and that
answer is worth more here than any outreach plan.
I am thinking particularly of DNS-record validation, signature
verification, clear
reporting of unsupported algorithms or formats, and interoperability
test cases.
On the third of those I have written here before, so one line will do: a
tool can report only what the specification names, so an algorithm a
verifier cannot evaluate needs a defined outcome of its own rather than
local policy.
The harder gap is predictive. A tool can tell you whether the recipes in
a message reconstruct, because the format and the procedure are
specified. It cannot tell an administrator whether their own setup will
produce a usable recipe, because the limits that decide it are not in
the specification and arguably could not be. In the current
implementations a recipe is capped at 1000 literal lines, and past that
cap the signing side emits a null recipe. A removed attachment becomes
literal lines and at 76 characters a thousand base64 lines carry some
57000 octets, so an attachment over roughly 56 kilobytes passes that cap
on its own.
Bron’s test site has more in it than this thread suggests: 66 negative
vectors across five verifiers, a signer gate of 25 fixtures and a corpus
stage that posts real messages through Mailman and Sympa and checks that
each list’s recipe rebuilds the signed instance under every verifier,
across charsets and transfer encodings. The real-message results
currently stop at -06.
Regards,
Vittorio Moccia
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
