It sounds like the algorithm advice is to use ML-DSA-44/65. At this point,
should someone just create an Internet-Draft to specify the PQC algorithm
for use with DKIM and DKIM2 and post it to the list?
I'd rather wait and see what DNSOP does, assuming they do it reasnably
soon.
-Wei
On Tue, Jul 28, 2026 at 8:38 AM John Levine <[email protected]> wrote:
It appears that Wei Chuang <[email protected]> said:
First I just wanted to summarize what I saw on the thread: Stephen Farrell
recommended PQC algorithm ML-DSA-44 or -65 and classical RSA/Ed25519.
Stephen also says -65 may be desirable to future proof. John Levine
agreed
ML-DSA-44 or -65 are reasonable, and inquired with Paul (Wouters)
<https://datatracker.ietf.org/person/[email protected]> who also
agreed. He also mentioned that DNSOPS was also looking at PQC concurrent
with us. Presumably we can look over there to see what they are thinking.
Steffen Nurpmeso suggested FAEST and MQOM PQC signature algorithms and
comparison website https://pqshield.github.io/nist-sigs-zoo/. Alexander
Stumpf suggests storing the SHA-3 hash of the PQC public key in DNS.
Richard says this will make PQC algorithms a special case, and complicate
DKIM2. Michael Deutschmann suggests avoiding the overhead of base64
encoding the PQC public key in DNS by using a new resource record. John
says that the DNS over TLS should be able to support PQC public key sizes,
and in case we should see what DNSOPS proposes.
Sounds right.
I also looked around DNSOPS for PQC advice. I found that they seem to be
actively working
<https://mailarchive.ietf.org/arch/msg/dnsop/Yr6A91U5gbjZ_L6NkMj8mbgTeQE/
on rules for handling greylisting algorithms on short notice via
draft-huque-dnsop-multi-alg-rules
<https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-alg-rules/>.
We
likely need a similar discussion for DKIM2 on how to gracefully handle
greylisting of the classical RSA/Ed25519 signature.
As I said in DNSOP, I think this is a bad idea becauase I don't think that
a typical DNS operator (or mail operator) knows enough about cryptography
to use such a feature sensibly.
If you think a signing algorithm is broken, just stop signing with it.
I think that DKIM signatures are likely to be pretty far down the list
of things attacked with PQ computers since they're short lived and the
stuff they sign is usually low value. If I want to phish people, there
are a lot cheaper ways than using a quantum computer to make a fake
DKIM signature.
Re the "AND" thing, if we really think that's important, we can add
a double signing algorithm where the keys and signatures are the
two individual ones concatenated. No need to add more complication
to the spec.
Also note that Stephen
suggested signing and validating ML-DSA-44/65 with RSA/Ed25519 a "AND".
Second, DNSSEC was able to more widely deploy
<https://www.icann.org/en/system/files/files/octo-033-04apr22-en.pdf> an
alternative to RSA i.e. ECDSA than DKIM which is predominantly RSA.
Key rotation in DKIM1 doesn't work in practice, mostly because you have
to have separate selectors for different algorithms which means double
signing, which risks losing mail in badly designed receivers that
penalize signatures they can't verify. I think we fixed this in DKIM2.
Also, the DNS crowd puts a lot of emphasis on keeping responses small.
While ed25519 is smaller than RSA, it's not enough smaller that it
would make any different in mail handling.
R's,
John
Regards,
John Levine, [email protected], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
