On Mon, Mar 23, 2026 at 06:41:19PM +0000, Scott Fluhrer (sfluhrer) wrote:
> Now, don't get me wrong - I'm not a QKD proponent by any means. I
> believe that the reliance on "trusted nodes" is a showstopper in most
> scenarios, and until they develop a workable "untrusted repeater", QKD
> security shouldn't be taken seriously. Side channel attacks are also
> bothersome. However, the ideal is not completely dead.
Back to the topic at hand, the first question to be resolved is whether
to respond. What is the process by which a decision to respond or not
is made?
If a response is appropropriate, I am happy to see at least one other
voice in support of proposing changes in Section 10.1, correcting what
TLS 1.3 currently offers, and in "Appendix I", to suggest at least
"psk_dhe_ke", or likely the more comprehensive 8773(bis) approach which
subsumes use of "psk_dhe_ke".
I don't think that it would be wise or productive to question the wisdom
and especially the motives of considering QKD in the first place.
Sceptical views on that topic (such as the Google and Cloudflare
documents linked upthread, for example) can be readily found by anyone
who cares to look, and a detailed analysis of QKD pros and cons seems
out of scope for the TLS WG.
It should be sufficient to suggest a defense in depth design, based on
8773(bis), combining QKD with a suitable asymmetric key agreement
method, and a suitable PQ signature scheme.
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
