Thank you Usama, bruh! Where to start in this thread. 1) to QKD or not to QKD, I am not going to in too many details now from what I can read because that would be a dozen of pages 1a) I was the one who gave a home to SG17 to the QKD side in 2018 as part of the first steps of the nascent SG17 incubation mechanism <https://www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-ICTSS-2024-1-PDF-E.pdf> 1b) and I did it despite the fact that I could have been vengeful given what I saw and suffered when I started at CERN in 1993: the hatred between physicists and mathematician. If Pete Resnick would have been here he would have been busy 24/24. No luck for me I was coming from the Russian Academy of Sciences in Moscow in social mathematics (funny how this is coming back now in other contexts!). And I was rapidly told and learned the hard way to HIDE that I was coming from the mathematics side.
1c) Anyways, all to say that I am frankly tired to see this battle. QKD is resolving a very specific problem in a very specific context: QKD is only responsible for generating symmetric cryptographic keys The NCSC has published several documents on QKD (see Quantum networking technologies | National Cyber Security Centre - NCSC.GOV.UK <https://www.google.com/url?q=https://www.ncsc.gov.uk/whitepaper/quantum-networking-technologies&source=gmail-imap&ust=1774884450000000&usg=AOvVaw2YF1VsFquKJp98dgbMOuJI>), and these documents recommend that QKD be implemented together with quantum-resistant authentication mechanisms. Saying that there is no market behind it is wrong, but this market is small and will stay small for a long time. The Chinese launched their Quantum satelite in 2016 that means that they must have convinced the Communist Party probably in the 90s. Whilst spatial links work with as long distance as the laser can do, it is not the case for terrestrial and I agree that the concept of the trusted node is a patch. On terrestrial QKD can only move to another level when physics relays are industrial class and I didn’t look in it in the last few years but when I realized what it needs to happen on the physics side and the astuces that the physicists were at, it left me speechless. I doubt this is the case still today. I had the chance to be invited in China to see the Chine NOC from satelite to terrestrial from Beijing to Shanghai … all the nodes working. In the meantime the Chinese have as well now 6m users on their QKD solutions. It is not just China and I know for a fact other countries and and for some cases a number of armies working on it and if you would know which ones everybody would be VERY surprised on this thread. Around me in Geneva nearly all the banks have QKD p2p links since perhaps 15 years and happy with it, with no trusted relays because they are beyond the 60/80km to connect their data centers. I don’t know how many satellites programs are in preparation but this is mushrooming and with BIG names of the industry behind More importantly I spoke to a 1st tier financial institution recently and a critical one that of course needs PQC readiness but wants TOO, QKD solutions. I have other use cases I cannot speak about. MY CONCLUSION: 1) I don’t like mono culture and mono solutions in security simply because by metaphor Mother Nature is not working like this and allows many ways to defend. I see defense like in biology where you can find multiple solutions to defend. Some are more or less mature at that’s ok. In the long run ’natural selection’ will tell us. But destroying one solution because some are on a dogmatic line to do so? No 2) It is frankly humanly speaking harassing for the QKD side to be constantly beaten up by some of the PQC side and even worse when it is coming from some governments. I find it painful, unkind, a frankly in todays world I don’t even see the point. As SG17 chair I took a very balanced and neutral view (no different than on anything btw) between PQC and QKD which are respectively in Q11 and Q15. For Q15 they even have the hybrid PQC/QKD work too 2) coming back to the problem of this LS a) reading the work item, to be totally transparent I don’t understand what it does in SG13 but that is now an internal ITU-T issue b) yet this tells me that at this stage this work item is trying to show a solution which is too generic and would require a lot of contextutalisation c) the context of the work item of Q13 and its LS to TLS working group is that TLS working group “should” answer it, in fact “must” from my point of view d) the answer should stay neutral and to the facts, I personally like the fixes on section 10.1 and on Appendix 1 proposed by Viktor The real questions that come to mind could be on the line (and thanks for Q15/17 team to help me here) A) is this work item Y.QKD-TLS trying to extend the application domain of QKD to a general-purpose internet security frameworks? Is this meaningful? B) what additional considerations (primarily from a security perspective are required? C) how such discussions should be coordinated with the IETF and IRTF QIRG? So if I restart from John’s first draft (thanks John) and consider all the inputs I would go with something in the line of a new beginning and and a new end. In fact points 2 and 3 from John look good to me given all the discussions on this thread. ----------- The IETF TLS working group reviewed LS2141 <https://datatracker.ietf.org/liaison/2141/> and expressed several concerns regarding Y.QKD-TLS. 1) the application domain of ITU-T Y.QKD-TLS seems to propose a general purpose internet security solution that goes way beyond the scope of QKD solutions. This work item should be recontextualised back to the QKD scope and limits. 2) The solution in ITU-T Y.QKD-TL would not enhance the security of TLS; it would severely weaken it. ITU-T should recommend migration to hybrid key exchange mechanisms such as X25519MLKEM768, which have already seen significant deployment. https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/ https://radar.cloudflare.com/post-quantum Potentially add Viktor’s old/new here in 10.1 + Usama + etc. 3) In appendix I, 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://www.rfc-editor.org/rfc/rfc8773.html https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis/ 4) The IETF TLS working group understanding of ITU-T entities is that such security issues should be coordinated by ITU-T SG17 (Security and Trust) and IRTF QIRG. ---------- Hope this helps Best Regards > On 22 Mar 2026, at 06:24, Muhammad Usama Sardar > <[email protected]> wrote: > > Hi, > > Speaking as member of ITU-T (in SG17; not the one initiating this LS), I want > to thank John for initiating a draft response, which I believe is right on > spot. Our chair, Arnaud, has kindly offered to do a review but I am aware > that he has quite some meetings and travel in the next 2 weeks. So I am > giving some quick feedback in the mean time. While I don't find anything > "inflammatory" in it (as someone has suggested), it's fine to make a few > editorial changes but make sure the core message is not lost in these > changes. Please remove RFC8773 and use only RFC8773bis. The reason is that > proposal [0] in RFC8773 is fully inconsistent with the key schedule of TLS > 1.3, since the very first key (Early Secret) is derived in a wrong way and > thus all subsequent secrets are wrong too. Technical reasoning is in [1]. > > Speaking as member of TLS WG: > > I disagree with Ekr. I believe TLS WG is the right place for this LS and TLS > WG has the right expertise as RFC8773bis is indeed a WG item of this WG. > > I disagree with Viktor with his mention of KEMs for RFC8446. That's not > correct. RFC8446 explicitly mentions (EC)DHE and never mentions KEMs. > > I completely agree with Stephen to not say anything about pure ML-KEM to > avoid that controversy here. Let's have a peaceful weekend without pure > ML-KEM thingy. 🙂 > > Sincerely, > > -Usama > > [0] https://www.rfc-editor.org/rfc/rfc8773.html#section-7-14 > <https://www.google.com/url?q=https://www.rfc-editor.org/rfc/rfc8773.html%23section-7-14&source=gmail-imap&ust=1774761947000000&usg=AOvVaw1uB3v8qilnw9DsiXnfN6N8> > [1] https://mailarchive.ietf.org/arch/msg/tls/6Wk82oBGd61rTK23DgfYb7BmRKM/ > <https://www.google.com/url?q=https://mailarchive.ietf.org/arch/msg/tls/6Wk82oBGd61rTK23DgfYb7BmRKM/&source=gmail-imap&ust=1774761947000000&usg=AOvVaw1-FXl2nYEt3ziU4g9_Y2_o> > > _______________________________________________ > 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]
