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

[John Mattsson <[e-mail]>]

Christian Huitema wrote:
>Link-layer encryption and transport layer encryption address different
>threats.

Yes, and they are often both needed.

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

I do not think it is redundant. While most web traffic is protected end-to-end, some traffic is not. Even when end-to-end protection is present, as you correctly describe, there is still value in protecting against attackers collecting or modifying metadata. Link-layer encryption also makes traffic analysis significantly harder, especially when combined with Traffic Flow Security. In general, I think link-layer protection is highly worthwhile, and for high-security links, I believe link-layer protection combined with Traffic Flow Security is valuable.

>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 we should recommend partial encryption of headers. Protection is not expensive if the system is designed to protect everything from the outset. By contrast, partial encryption adds complexity and creates an awkward mix of partially exposed information, such as TLS ClientHello data and other traffic that may still remain unencrypted.

Cheers,
John Preuß Mattsson

From: Christian Huitema <[e-mail]>
Date: Tuesday, 7 April 2026 at 19:34
To: Nico Williams <[e-mail]>, Muhammad Usama Sardar <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [TLS] Re: New Liaison Statement, "Liaison communication to IETF regarding draft-ietf-tls-mlkem"


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

_______________________________________________
TLS mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]