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

[Muhammad Usama Sardar <[e-mail]>]

Hi Nico,

Now returning back to this email with the agreement:

    Outer TLS: Network layer: use pure ML-KEM

    Inner TLS: Application layer: use ML-KEM + ECDHE

Since Christian and John are talking about "link" layer, I'm lost 
whether we are all talking about the same layering. But in this email, I 
will continue with what we both agreed in [0,1], and later on spend some 
cycles to understand what they are saying.

On 07.04.26 02:23, Nico Williams wrote:
> On Tue, Apr 07, 2026 at 01:19:45AM +0200, Muhammad Usama Sardar wrote:
>> On 07.04.26 00:39, Nico Williams wrote:
>>> We've seen this argument made before on this list.  If you're double-
>>> encrypting, and each layer uses different algorithms...
>> Yes, I vaguely recall John mentioning this, but was that actually in hybrid
>> vs. non-hybrid context?
>>
>> My point was that if the overhead of adding ECDHE is considered unacceptable
>> (apparently that's the argument for use of pure PQ), the overhead of
>> creating two connections should be surely unacceptable. I would expect that
>> for systems where you want defense-in-depth (e.g., NSS -- see below), you
>> actually don't care about efficiency so much. The goal there is high
>> security.
> I'd expect that 802.11x key exchanges are infrequent and once connected
> asynchronous, so performance is less of a concern at that layer than at
> the application layer.

Let me translate that to RFC8446 terminology:

Handshake for outer TLS will not be so frequent, i.e., TLS "connections" 
at network layer will be long-lived.

Why do you say "key exchanges" only? They should do "authentication" as 
well, no? I mean full handshake, right?

What do you mean by "asynchronous"?Are you thinking about PSK-based 
handshake?

> What I'm saying is that I am much less concerned about non-hybrid PQ at
> the network layer than at the application layer.
concerned in terms of performance or security?
>> So how exactly would double-encryption work in this context? You establish
>> pure PQ TLS at network layer -- that I understand. But can you share more
>> insights about the application layer TLS? Like, how does it distinguish the
>> control signals (TLS messages) of the /application layer TLS/ from the
>> actual application traffic? Does the application layer TLS reuse some of the
>> keys from the network layer TLS? What is the binding between the two?Are you
>> aware of any complete specifications?
> The application (e.g., a browser), just does TLS as usual with
> RECOMMENDED=Y algorithms and gets hybrid PQ.
This is what confused me and that's why I asked [0]. There is nothing in 
hybrid with RECOMMENDED = Y. Maybe you mean once 
draft-usama-tls-ecdhe-mlkem-update is published?
>    The application is not
> aware of what security is provided by the network layer.
> Double encryption just happens because:
>
> a) the network (802.11x, IPsec) requires it policy-wise,
>
> b) the application uses TLS (or similar) independetly of the network
>     being encrypted.

I am very lost now. I thought in [1], you agreed that there are two 
nested TLS connections, i.e., TLS-over-TLS rather than TLS-over-IPSec.

Are you aware of any complete specs of such double encryption from which 
I can create a model?

> ASIDE: Long ago I had wanted to be able to make use of network layer
>         cryptography at the application layer, thus I wrote RFC 5056 (On
>         Channel Bindings) to expand on RFC 2743's nebulous concept of
>         channel binding.
After reading this, I realized that Nicolas == Nico 😇 I happen to be 
your fan for this work 😉 because I have been researching channel 
bindings (RFC5056 and RFC9266) recently.
>         All of this was made unnecessary and obsolete by things like the
>         disappearance of multi-user NFS clients, the appearance of NICs
>         that can offload TCP and even TLS, etc.
For TLS, did you mean RFC9266?
>> Where are the keys of both TLS stored actually? Is there a real case that
>> the keys of one TLS (say network layer) will be leaked while the other one
>> not? If the keys are all stored at the same place, adding even 10 layers of
>> encryption is not helpful. So instead of doing double encryption, I believe
>> one should actually do attested TLS in post-handshake attestation topology
>> (draft-fossati-seat-expat), which provides a second root of trust, without
>> the need to re-establish a connection.
> No, compromise of one layer will not compromise the other.  The two
> layers are independent.
I meant if server is compromised, then all keys of the server are 
compromised, except if keys are stored in different storage mechanisms. 
As I mentioned, our design of attested TLS provides an independent root 
of trust. Maybe we can suggest IEEE 802.11 to do this, so that if their 
ML-KEM thingy breaks, attestation can protect them.
>>> IIUC NSA mandates double-encryption.
>> My understanding is that it is for high-stake systems -- known as National
>> Security Systems (NSS). For non-NSS, it is not mandatory.
> I would expect that application-layer security is always mandatory, thus
> only network layer security would ever be optional.  Given that, if the
> network uses non-hybrid PQ, it's not that big a deal.

Now I am even more lost. If network layer TLS is optional, there can be 
active MITM, no?

So if there is no channel binding between the two layers, then how does 
one endpoint know about the authentication done at other layer?

Best regards,

-Usama

[0] https://mailarchive.ietf.org/arch/msg/tls/zKFOBbA65wkZ7k2iQ6o_xmXarWk/

[1] https://mailarchive.ietf.org/arch/msg/tls/1Cj_Jb7eh9LVyIh42jyWcQD3IiU/