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

[Christian Huitema <[e-mail]>]

On 4/7/2026 8:02 AM, Nico Williams wrote:
> 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.)

Link-layer encryption and transport layer encryption address different 
threats.

TLS protects the content of the exchange, but does not protect meta-data 
in IP, TCP or UDP headers. Link layer encryption is often touted as 
protecting all the data, but since it is removed when data is routed to 
another link, it is at best a partial protection, and a somewhat 
redundant one at that since most connections use some kind of end to end 
encryption. Logically, link layer encryption should focus on two 
functions: protect against collection meta data by listening to wireless 
transmission or by tapping optical fibers; and, provide access control 
and prevent third parties interfering with the network.


Maybe we should use the liaison with IEEE to mention that we would be 
happy if link-layer encryption focused only on the first bytes of the 
message, covering IP and TCP/UDP headers, and link layer addresses too 
if that was possible. If they can devise something like that, reduce the 
cost of redundant encryption, and achieve better performance, they 
should do it!

-- Christian Huitema