On Sat, Mar 21, 2026 at 02:59:34PM -0700, Eric Rescorla wrote:
> I'm not particularly a fan of QKD, but I don't really understand why
> we have to weigh in on this LS.
>
> >From the perspective of TLS, the integration proposed here is just an
> external PSK, and the security of the system depends entirely on how
> that PSK is established. It's possible (likely?) that it will be
> insecure in the fashion John suggests, but this design also seems
> compatible with stronger modes of operation, e.g., establishing a
> fresh key with each connection.
>
> ISTM that the security of the overall system depends primarily on the
> strength of the QKD and the key management practices used with it,
> both of which are largely outside of the scope of this WG.
The core of the objection, that started this thread, is to text in the
draft at:
https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2025-09-03-itu-t-sg-13-ops-work-progress-on-quantum-key-distribution-qkd-network-in-itu-t-sg13-as-of-july-2025-attachment-12.pdf
in which "Appendex I", bottom of page 9 + top of page 10, reads:
1) The TLS client sends “Client Hello” message to the TLS server.
In "Client Hello" message, the "psk_key_exchange_modes"
extension is provided with the value of "psk_ke" which means the
PSK-only key establishment. In the "pre_shared_key" extension,
there is a list of PSK identities that the client is willing to
negotiate with the server.
So "psk_ke" is singled out as the way that the QKD PSK is to be used
TLS. There's room to be sceptical about the wisdom of that detail of
the design.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
