Viktor Dukhovni wrote: >or some other less inflammatory formulation. It is a sad world if a straightforward fact is considered inflammatory. SIGINT agencies have sold "unbreakable" hardware in the past and will do so again. https://www.washingtonpost.com/graphics/2020/world/national-security/cia-crypto-encryption-machines-espionage/
People building, standardizing, and using QKD seem to have little to no knowledge of cryptography and security. The ITU-T Y.QKD-TL system would allow a dishonest QKD hardware manufacturer not only to passively eavesdrop on all communication, but also to impersonate endpoints and inject traffic. I think the IETF has a moral responsibility to inform ITU-T about these risks. Cheers, John Preuß Mattsson P.S. Note that I find Bernstein's claims that ML-KEM is an NSA backdoor to be absurd for the following reasons: - Kyber was designed mostly by non-U.S. cryptographers, based on decades of global research, and was analyzed and selected in an open competition. - I do not think NIST trusts the NSA at all anymore. During a presentation at the Accordion workshop, when I spontaneously said that NIST would likely follow what the NSA wanted for their systems, an NSA cryptographer in the front row burst into laughter. - NIST standards are recommendations for U.S. industry and the U.S. federal government. I do not believe that the NSA would want U.S. industry and the U.S. federal government to use weak cryptography that China or Russia could break. Similarly, if NCCG recommends something for Chinese industry, they likely believe it is secure and not breakable by the U.S. From: Nico Williams <[email protected]> Date: Saturday, 21 March 2026 at 15:01 To: [email protected] <[email protected]> Subject: [TLS] Re: LS on the work item related to QKD and TLS integration framework in SG13 On Sat, Mar 21, 2026 at 03:44:51PM +1100, Viktor Dukhovni wrote: > On Fri, Mar 20, 2026 at 09:13:16PM +0000, John Mattsson wrote: > > > I am worried about the ITU-T work on TLS, which seems to significantly > > lower the security. > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fliaison%2F2141%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C810a954955c84e9fc5c708de87179fe0%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639096732698049450%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mTaJDmj8KLLCXqqcdqDwJaHrks4rCTLWS8IpfZoveOw%3D&reserved=0<https://datatracker.ietf.org/liaison/2141/> > > I agree that QKD is presently a combination of interesting physics and > commercial snake-oil. That said I'd look to modify the below, with the > aim of making the critique more likely to be accepted as constructive. It has been since the beginning of QKD. It's been so for decades. I'm not sure what can be done to make QKD actually useful, but it isn't now. > > I suggest that TLS WG replies as follows: > > > > ---------------------------------- > > > > [...] > > So far, mostly fine, but... > > > This is exactly the kind of statements one would expect from a > > hardware vendor secretly influenced by a SIGINT organization. > > I don't believe that the above sentence will help to sway those > considering QKD to take a more sceptical position. Instead it > would be more productive to say something along the lines of: > > Such marketing claims should not be taken at face value. Rather, > one may concede that in highly specialised point-to-point > deployments QKD-derived keying material might be combined with an > established asymmetric key-agreement scheme to yield a shared secret > that is resilient against attacks, so long as either scheme is > secure. > > or some other less inflammatory formulation. +1 > > The use of psk_ke symmetric key distribution significantly weakens the > > security of TLS by removing asymmetric cryptographic algorithms for > > key exchange and authentication. The psk_ke mode was designed for > > constrained IoT environments, is disabled in many TLS libraries, and > > is not suitable for high-security use cases such as critical > > infrastructure. If PSK-based solutions for quantum resistance are > > used, they should follow RFC 8773 (and its revision, 8773bis), which > > retains both certificate-based authentication and ephemeral key > > exchange. This ensures that security is not weakened by the > > introduction of PSK-based mechanisms for quantum resistance. > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8773.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C810a954955c84e9fc5c708de87179fe0%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639096732698065122%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=H23U6qPYJnL1RN8xO7V5eFjCNIwOthrTNID8%2Fc2c8Sc%3D&reserved=0<https://www.rfc-editor.org/rfc/rfc8773.html> > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-tls-8773bis%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C810a954955c84e9fc5c708de87179fe0%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639096732698075124%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=DVV7eX9HE%2FhJW3vZzbyEPDr0YBgUxel72GD8hslZmjU%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis/> > > Mind you, given a meticulously operated KDC (not QKD), and robust > distribution of initial keying material when enrolling new nodes in the > KDC database, "psk_ke" may be an adequately secure quantum-resistant > key-establishment mechanism. Of course, in many deployments, > "psk_dhe_ke" is just as practical and at least as secure. Yes. Even in the case of Kerberos KDCs we have ways to use DHE and PKI (PKINIT). For TLS in particular DHE KE buys PFS, and we should want that even if symmetric PSK adds a measure of CRQC resistance -- we can get both, so why not. Nico -- _______________________________________________ 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]
