Ken Kubota wrote: >OpenSSH reached the appropriate conclusion by adopting a hybrid approach [1].
TLS has adopted hybrid key exchange, and X25519MLKEM768 has become the de facto standard in both implementations and specifications (with RECOMMENDED = Y). Standalone ML-KEM is not replacing X25519MLKEM768. Where do the repeated and incorrect claims about “replacing,” “removing,” or “weakening” originate from? I do not agree that OpenSSH has reached the appropriate conclusions. While OpenSSL and wolfSSL already supports PQC authentication, OpenSSH does not. Additionally, OpenSSH is coupling mlkem768x25519 (which internally uses SHA-3) with SHA-256. In contrast, TLS X25519MLKEM768 is independent of the underlying SHA-2/SHA-3 choice, and TLS is now discussing SHA-3-based cipher suites. Cheers, John Preuß Mattsson From: Ken Kubota <[email protected]> Date: Tuesday, 7 July 2026 at 06:54 To: [email protected] <[email protected]> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] I object to the proposal to publish draft-ietf-tls-mlkem-*. Replacing a hybrid (double-encryption) mechanism with a non-hybrid (single-encryption) mechanism introduces significant and obvious risks without providing any corresponding benefits. Given that, during the recent NIST PQC standardization process, even one of the finalists dropped out, removing a safety belt and relying exclusively on a relatively new algorithm not only jeopardizes cryptographic security but also appears irresponsible. OpenSSH reached the appropriate conclusion by adopting a hybrid approach [1]. With regard to the process itself, genuine consensus (including a "rough consensus") cannot be achieved under conditions of censorship [2]. I find it astonishing that Daniel J. Bernstein, a cryptographer, whose algorithms run half of the internet or more and who has an outstanding track record of pushing back against attempts to weaken cryptography, has received no response for nearly two months (14 Jun 2025 to 13 Aug 2025), even after providing, as requested, a permanent link [3]. By contrast, when two NSA employees openly support an approach [4] that clearly reduces or potentially compromises cryptographic security, the obvious conflict of interest raises the broader question of whether IETF procedures should be reviewed. Kind regards, Ken Kubota ____________________________________________________ Ken Kubota https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoi.org%2F10.4444%2F100&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0673f53038b84cb0c64008dedbe3be45%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639189968638677868%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=AJXE9Ge5ceIOUeduZr7JkW3%2F3vD8ANxMyVQDIzjGfYo%3D&reserved=0<https://doi.org/10.4444/100> [1] "New features ------------ * ssh(1), sshd(8): use the hybrid Streamlined NTRU Prime + x25519 key exchange method by default ("[email protected]"). The NTRU algorithm is believed to resist attacks enabled by future quantum computers and is paired with the X25519 ECDH key exchange (the previous default) as a backstop against any weaknesses in NTRU Prime that may be discovered in the future. The combination ensures that the hybrid exchange offers at least as good security as the status quo. We are making this change now (i.e. ahead of cryptographically- relevant quantum computers) to prevent "capture now, decrypt later" attacks where an adversary who can record and store SSH session ciphertext would be able to decrypt it once a sufficiently advanced quantum computer is available." https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openssh.org%2Ftxt%2Frelease-9.0&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0673f53038b84cb0c64008dedbe3be45%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639189968638702892%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=ksUMvJVHo%2BQgshsB63q45lGTezAfLyI7Cq8Hw4aVEcM%3D&reserved=0<https://www.openssh.org/txt/release-9.0> [2] "Consensus decision making The general rule on how Working Groups make decisions is that the Working Group has to come to "rough consensus", meaning that a very large majority of those who care must agree, and that those in the minority have had a chance to explain why and their points have been addressed, even if they were not agreed with." https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fprocess%2Fwgs%2F%23consensus&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0673f53038b84cb0c64008dedbe3be45%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639189968638723621%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=bo6WRJWLMUKaC5k50xB%2BqdqTimVOav2%2BBEF1GnZjvI8%3D&reserved=0<https://www.ietf.org/process/wgs/#consensus> [3] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FX8-3pmioGxFZX3T0tRsdxPWKx3I%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0673f53038b84cb0c64008dedbe3be45%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639189968638741271%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=x9PhiqCYT7mvkZO5YS1cYXXYsrheLJL2HF7U5Df6Vn8%3D&reserved=0<https://mailarchive.ietf.org/arch/msg/tls/X8-3pmioGxFZX3T0tRsdxPWKx3I/> [4] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FXIckyKVIEgKNus-koXOLooFpU54%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0673f53038b84cb0c64008dedbe3be45%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639189968638757900%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=d1o8UTyChruCEPVtD7AQK7sgfqZrjm3uvd7wRSm4y6s%3D&reserved=0<https://mailarchive.ietf.org/arch/msg/tls/XIckyKVIEgKNus-koXOLooFpU54/> and https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FZX2lWkx4FApNZ8q787wIEpn7USg%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C0673f53038b84cb0c64008dedbe3be45%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639189968638774558%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=iSbt31DITN4idhohJLw5gj%2F4ICbWyn5Cg3wslzSE2rc%3D&reserved=0<https://mailarchive.ietf.org/arch/msg/tls/ZX2lWkx4FApNZ8q787wIEpn7USg/> _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
