Viktor Dukhovni wrote: > It makes sense to recommend "psk_dhe_ke" over "psk_ke", with > X25519MLKEM768 as the "dhe".
Agree Stephen Farrell wrote: >I'd not say anything about combining QKD with pure ML-KEM as >that'd likely just add needless controversy. Agree. I think it’s best to keep it simple and use X25519MLKEM768 as the sole example. Since the external PSKs are also used for TLS authentication, I think the full recommendation should be to follow RFC8773(bis) with X25519MLKEM768, as suggested earlier. Cheers, John Preuß Mattsson From: Stephen Farrell <[email protected]> Date: Sunday, 22 March 2026 at 09:55 To: [email protected] <[email protected]> Subject: [TLS] Re: LS on the work item related to QKD and TLS integration framework in SG13 I've not read into the LS but going from mails to the list: On 22/03/2026 01:35, Viktor Dukhovni wrote: > It makes sense to recommend "psk_dhe_ke" over "psk_ke", with > X25519MLKEM768 as the "dhe". The above seems like the meat of a very reasonable response. I think text that (correctly) says that depending only on QKD would be silly is also good, and I'm fine that whoever crafts the LS response text finds the best language for that. The proposals already suggested seem almost fine. I'd not say anything about combining QKD with pure ML-KEM as that'd likely just add needless controversy. Cheers, S.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
