[TLS] Re: New Liaison Statement, "Liaison communication to IETF regarding draft-ietf-tls-mlkem"

[Nico Williams <[e-mail]>]

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
--