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.
What I'm saying is that I am much less concerned about non-hybrid PQ at
the network layer than at the application layer.
> 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.
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. My idea at the time (2003) was to eventually
define channels and channel binding for IPsec (RFC 5660 defines
IPsec channels) and then make use of that in NFSv4 and iSCSI to
let the network do all the heavy lifting for _session_
cryptography and thus also benefit from needing fewer
cryptographic contexts on multi-user NFSv4 clients. At the time
Sun Microsystems, Inc., (RIP) had a NIC (Neptune) that could
offload ESP.
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.
Still, it's much easier to do HW offload of ESP than it is to do
HW offload of TLS. The architecture I had in mind was sound, but
it was already about 15 years too late for it back then.
> 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.
Nico
--
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
