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 + ECDHESince 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?
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?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.
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.
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?
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.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.
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/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
