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]
