Ken Kubota wrote: >OpenSSH's stated goal was to prevent "capture now, decrypt later" attacks, and >it achieves that objective successfully. By contrast, breaking authentication >using quantum computing is currently not a realistic threat model.
That is very clearly the wrong goal if you have long-term authentication keys. Many long-lived devices ship with SSH, and it is a fact that the authentication keys on many of them are never updated. One can debate when CRQCs will arrive, but if they arrive in the mid-2030s as OpenSSH suggests on its website,, the migration of long-term authentication keys should already have been completed. Future CRCQs breaking long-term signature keys is a very realistic threat model. In fact, the value to an attacker is much greater than that of breaking a single ephemeral key exchange. Cheers, John Preuß Mattsson From: Ken Kubota <[email protected]> Date: Tuesday, 7 July 2026 at 15:57 To: John Mattsson <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [TLS] 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 ] It has already been pointed out earlier on this mailing list [1] that RECOMMENDED = N is not a remedy, since the non-hybrid mechanism would still be implemented and used, effectively (!) weakening internet security by encouraging its deployment. Certain organizations (see the conflict-of-interest discussion) evidently have an interest in this. OpenSSH's stated goal was to prevent "capture now, decrypt later" attacks, and it achieves that objective successfully. By contrast, breaking authentication using quantum computing is currently not a realistic threat model. Given the expected time horizon of at least several years before practical quantum computers become available, and considering the risks of deploying (and thereby widely disseminating) an algorithm with only a limited history of public cryptanalysis, postponing PQC authentication for some time is a reasonable decision. Both the SHA-2 and SHA-3 families of hash functions have demonstrated sufficient cryptographic strength for this purpose (length-extension attacks are not relevant in this context). Consequently, there is no disadvantage in using both. (For future long-term projects, however, I would indeed prefer SHA-3 hash algorithms, as they appear to provide a somewhat larger security margin while also being inherently resistant to length-extension attacks.) 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%7Cbf9e93c0cbfa451f18cd08dedc2fa676%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639190294426656424%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yAfWB6uhvPc%2B3qbkEdaZC2daedm%2Brp85Y8ark6QGSy8%3D&reserved=0<https://doi.org/10.4444/100> [1] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Ftls%2FPvC-J2Y0aOgG2K1CewZK5TItWX0%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cbf9e93c0cbfa451f18cd08dedc2fa676%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639190294426686659%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=driLBc1ChZC%2Fb0TGTOc8iM2RMuFB%2B5JZch9clcR1XE0%3D&reserved=0<https://mailarchive.ietf.org/arch/msg/tls/PvC-J2Y0aOgG2K1CewZK5TItWX0/> > Am 07.07.2026 um 08:53 schrieb John Mattsson > <[email protected]>: > > 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%7Cbf9e93c0cbfa451f18cd08dedc2fa676%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639190294426705748%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JiuMZBfCrNO3azpxdCiGJuilswpPzZ2bH7Ej4UMKM4I%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%7Cbf9e93c0cbfa451f18cd08dedc2fa676%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639190294426723556%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7l%2FdBVEJYW3VApeoJqRKiWFnsZ%2BDHl5FSuJbnj1bRYM%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%7Cbf9e93c0cbfa451f18cd08dedc2fa676%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639190294426750457%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mu7zQAQFlMEqlHpXukZ30wmQWZCO%2FcUTtb6UtA23JOQ%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%7Cbf9e93c0cbfa451f18cd08dedc2fa676%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639190294426775454%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=KF3Ey6UYiR8l8Cjb36gpaIcL8AQ32JdoWX%2Fp813wZ90%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%7Cbf9e93c0cbfa451f18cd08dedc2fa676%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639190294426795322%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cNa6LvRB3voVVEIjedCzrTSYZRR4%2FSW1dapLxGu8sQM%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%7Cbf9e93c0cbfa451f18cd08dedc2fa676%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639190294426814748%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=kmBOeijMdAKU1lvG6r8jboQV%2BSCS9VzO9uz7QxehUPM%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]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
