On 4/7/2026 8:02 AM, Nico Williams wrote:
On Tue, Apr 07, 2026 at 11:59:45AM +0200, Muhammad Usama Sardar wrote:
Thanks Nico for sharing your insights. I think this is useful discussion and
might help us make some use case for pure ML-KEM.
To be on the same page, framing the problem for clean discussion. Could you
please clarify which one of the following did you mean?
Outer TLS: Network layer: use pure ML-KEM
Inner TLS: Application layer: use ML-KEM + ECDHE
This one. Remember, the two layers are effectively independent. If you
want to protect against CRQCs your options will be pure PQ or hybrid PQ,
and here IEEE seems to want pure PQ while we seem to want hybrid PQ,
thus it's this picture above.
(Except the "outer TLS" is only for negotiation of keys. The actual
packets are not encrypted using TLS but something else more akin to
DTLS.)
Link-layer encryption and transport layer encryption address different
threats.
TLS protects the content of the exchange, but does not protect meta-data
in IP, TCP or UDP headers. Link layer encryption is often touted as
protecting all the data, but since it is removed when data is routed to
another link, it is at best a partial protection, and a somewhat
redundant one at that since most connections use some kind of end to end
encryption. Logically, link layer encryption should focus on two
functions: protect against collection meta data by listening to wireless
transmission or by tapping optical fibers; and, provide access control
and prevent third parties interfering with the network.
Maybe we should use the liaison with IEEE to mention that we would be
happy if link-layer encryption focused only on the first bytes of the
message, covering IP and TCP/UDP headers, and link layer addresses too
if that was possible. If they can devise something like that, reduce the
cost of redundant encryption, and achieve better performance, they
should do it!
-- Christian Huitema
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
