+1 I think that is a very good diplomatic summary.
John From: Ilari Liusvaara <[email protected]> Date: Tuesday, 24 March 2026 at 16:50 To: [email protected] <[email protected]> Subject: [TLS] Re: [EXTERNAL] Re: LS on the work item related to QKD and TLS integration framework in SG13 On Mon, Mar 23, 2026 at 03:03:45PM +0000, John Mattsson wrote: > - I think a reply from TLS should include the technical analysis of > their use of the TLS protocol. That is why they are writing TLS WG. > The only reason of not saying that psk_ke for external PSKs is a > very bad choice would be to save the face of RFC 8446. If one takes the premise of using QKD with TLS (despite all the deployment issues with QKD): ------------------------------------------------------------------------ Any use of QKD with TLS should be done such that failure of QKD does not degrade security of TLS: - The PSK Key Exchange Mode should be 1 (psk_dhe_ke) so that the QKD key gets combined with result of internal TLS key exchange. - The TLS key exchange group should be 4588 (X25519MLKEM768) so both X25519 and ML-KEM-768 are used. - The extension 33 (tls_cert_with_extern_psk) should be used, so TLS also performs traditional certificate authentication. Then in scenario where Cryptographically Relevant Quantum Computers have rendered traditional cryptography moot: - The TLS key exchange group can be 513 (MLKEM768) instead, to drop the use of X25519. - The certificates should use ML-DSA. While SLH-DSA would be even more secure, it has bad performance (slow and big signatures). ------------------------------------------------------------------------ -Ilari _______________________________________________ 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]
