> On 24 Mar 2026, at 05:30, Viktor Dukhovni <[email protected]> wrote:
> 
> 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?

There is quite of an update here:
https://datatracker.ietf.org/doc/html/draft-iab-rfc4052bis-02
https://datatracker.ietf.org/doc/html/draft-iab-rfc4053bis-01
see
https://mailarchive.ietf.org/arch/msg/architecture-discuss/eNc39HP9Us6WtWV1HEuOCt86OKo/

> 
> 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".
You have another voice in support, I find your proposals very good, see my 
previous email and see the placeholder in the draft answer

> 
> 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.
+1

> 
> 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.
And you don’t need to go in any details at this stage. As I wrote the work item 
seems to be for a generic and probably too wide use case.

Let me know on the second part of my email if you can bring back your text in 
the yellow placeholder and we can roll the ball from there while we check the 
procedure.

Best Regards
 
> 
> -- 
>    Viktor.  🇺🇦 Слава Україні!
> 
> _______________________________________________
> 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]

Reply via email to