We seem to have gotten reasonable advice in this thread including from Paul. To summarize: ML-DSA-44/65 seems to be a reasonable starting point for DKIM2 PQC. We still should track other work b/c it sounds like better algorithms are potentially available, and need more time for cryptographers to gain confidence in them. I agree with John and Richard that we shouldn't do anything exotic with hashes of public keys in DNS nor deploy new RRs.
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. Next I went down the rabbit hole and started looking at Steffen's comparison table and others: - https://pqshield.github.io/nist-sigs-zoo/ (everything) - https://cachee.ai/pq-key-sizes (public key scaling normalized against Ed25519) - https://blog.cloudflare.com/ml-dsa-will-have-to-do/#the-signature-algorithms (runtime scaling normalized against ML-DSA-44) >From that, another candidate algorithm is FN-DSA-512 and FN-DSA-1024 that has good runtime, and better key and signature sizes than ML-DSA-44. It is undergoing standardization as FIPS 206 for resource constrained applications such as DKIM2. However the Cloudflare blogpost notes problems <https://blog.cloudflare.com/ml-dsa-will-have-to-do/#fn-dsa-small-key-and-signatures-subtle-signing> with FN-DSA. 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. 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. DNSOPS also discussed <https://mailarchive.ietf.org/arch/msg/dnsop/P01x1OC4FpVlwvGVNJML8dbrtjs/> SQIsign since it has particularly good sizes and runtime, though it's even further out from standardization. One of Google's PQC leads, Sophie Schmieg, had crypto advice <https://mailarchive.ietf.org/arch/msg/dnsop/rczbGcPwu8a1af9zoHjZe6OxJDc/> there that gave confidence levels for algorithms. Basically she says that ML-DSA is the only realistic algorithm by 2030. The Cloudflare blogpost <https://blog.cloudflare.com/ml-dsa-will-have-to-do/#the-signature-algorithms> says the same thing. -Wei On Fri, Jul 24, 2026 at 5:31 AM Murray S. Kucherawy <[email protected]> wrote: > On Fri, Jun 19, 2026 at 8:14 PM Wei Chuang <weihaw= > [email protected]> wrote: > >> We've written the following DKIM threat model as a starting point: >> >> The DKIM Working Group requests guidance from the CFRG in identifying the >> most appropriate Post-Quantum Cryptography (PQC) digital signature >> algorithm for DomainKeys Identified Mail. Our primary threat model focuses >> on an adversary utilizing quantum analytic key compromise to forge >> signatures, thereby enabling widespread domain spoofing. To maintain the >> reliability of global email delivery, any proposed algorithm must navigate >> DKIM's strict operational constraints: public keys are distributed via DNS >> TXT records (imposing severe sensitivity to UDP payload limits and TCP >> fallback latency), and signatures are transmitted within standard email >> headers. Furthermore, DKIM’s existing architecture evaluates the message >> hash independently of the signature generation to facilitate the processing >> of streamed email bodies. We seek CFRG’s expertise in selecting an >> algorithm that optimizes for these stringent size constraints while >> providing secure, practical recommendations for accommodating our >> pre-hashed input model. >> >> We welcome feedback on the above threat model for the CFRG. >> > > There were several replies to this. Given those replies, it's unclear to > me whether we should present the text as-is to Paul or if those replies > included or suggested changes we need to incorporate first. > > Can we get some guidance here, particularly from people that replied > upthread? > > -MSK > > >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
