On Tue, Apr 07, 2026 at 11:59:45AM +0200, Muhammad Usama Sardar wrote: > Thanks Nico for sharing your insights. I think this is useful discussion and > might help us make some use case for pure ML-KEM. > > To be on the same page, framing the problem for clean discussion. Could you > please clarify which one of the following did you mean? > > Outer TLS: Network layer: use pure ML-KEM > > Inner TLS: Application layer: use ML-KEM + ECDHE
This one. Remember, the two layers are effectively independent. If you want to protect against CRQCs your options will be pure PQ or hybrid PQ, and here IEEE seems to want pure PQ while we seem to want hybrid PQ, thus it's this picture above. (Except the "outer TLS" is only for negotiation of keys. The actual packets are not encrypted using TLS but something else more akin to DTLS.) > OR > > Outer TLS: Network layer: use pure ML-KEM > > Inner TLS: Application layer: use ECDHE Not this one. > What I still find confusing in both cases is that if outer TLS is > long-lived, then performance benefit of pure ML-KEM (vs. ML-KEM + ECDHE) > should not be a valid argument. That is even if I accept that the > performance impact of ECDHE is significant, it is just one-time > bootstrapping cost for a connection that will be lasting for long-term. What > am I missing? I agree, it's the app that will be doing more key exchanges, thus the app that would benefite from pure PQ performance-wise. The question for you is: should we, and _can_ we dictate the choice of hybrid or pure PQ for 802.11x? I think the answer to that is no -- we should advise the IEEE, but they can do as they please. Nico -- _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
