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? -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 >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
