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

[Russ Housley <[e-mail]>]

Christian:

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

I do not think these observations would surprise anyone ay IEEE 802.11.  The liaison statement says that they really want to use EAP-TLS with PQC algorithms.

Russ