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 -- _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
