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

[Nico Williams <[e-mail]>]

On Wed, Apr 08, 2026 at 01:15:19AM +0200, Muhammad Usama Sardar wrote:
> 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.

You wrote "Outer TLS: Network layer", but what is the "network layer"?
It could mean the link layer, or IPsec.  Anyways, in the context of IEEE
it means "the link layer", so it's point-to-point, and at best
hop-by-hop, while applications are end-to-end, so we're talking about:

 - how nodes connect to switches (think Ethernet)
 - how nodes connect to WiFi and other wireless protocols

> On 07.04.26 02:23, Nico Williams wrote:
> > 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?

The _packets_ will not be using TLS because they are unordered.

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

I'm talking about the nodes involved re-keying periodically, which
should not pause traffic flows.

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

Security.

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

Well, right, that has to get fixed too.

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

Nested, yes, in a very loose sense.  The link layer is encrypting, but
the link layer is one hop, and the application is end-to-end -- the
application _cannot_ make use of link layer security because it can't
ensure that every hop will use appropriate security, so the application
has to use TLS itself.

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

It's very simple: the network link layer is encrypted separately from
what happens above TCP, and there is no connection whatsoever.

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

Hope it helps :)

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

Yes.

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

How does attestation protect against catastrophic cryptanalysis?

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

Yes, but TLS is supposed to be resistant to MITMs.

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

It doesn't.  They are independent.  Neither knows about the other.

Nico
--