[Cryptography] The TLS-LTS draft expires in August 2026

[Paul Wouters]

On Mon, 8 Jun 2026, Ralf Senderek wrote:

> On Mon, 8 Jun 2026, Salz, Rich wrote:
> 
> > [1] https://www.ietf.org/archive/id/draft-ietf-tls-tls12-frozen-08.html
> > [2] https://mailarchive.ietf.org/arch/msg/tls/aYsIi0HjV3ZagCFB9n_eRpFsBZ4/
> > [3] https://mailarchive.ietf.org/arch/browse/tls/?q="tls-lts"
> 
> Thank you very much for the pointers, they are an insightful
> read.
> 
> [1] which makes the point that 
>
>    "This document specifies that outside of urgent security fixes
>    (as determine by TLS WG consensus),
>    and the exceptions listed in Section 4, no changes will be approved for TLS 1.2."
> 
> But TLS-LTS does in no way require such changes to TLS 1.2.

I was the Area Director for TLS at the time. My memory is that doing an
"LTS version" would mean there could still be future changes to the TLS
1.2 protocol, but the TLS WG decided to freeze all work on 1.2. This is
the typical way how IETF encourages moving to the next major version
of a protocol.  Also, since TLS 1.2 has no PQC support, it is kinda
contradicting to work on a "stable long term TLS 1.2", as most people
(I know Peter is not among them) want protection capability against
PQ in their "long term" TLS implementations.

> So it seems, GCM is seen as superior to CBC mode, and many websites have already
> chosen to use only GCM mode for AES with TLS-1.2.

Yes, not only due to security reasons but also because of its superior
speed (and less CPU usage) due to GCM hardware offload.

> This is ignoring the fact that GCM can fail in a catastrophic way if
> nonces are reused, which is not the case with CBC mode.

My understanding is that the way this is integrated in TLS and IKEv2, is that
it would be really hard to re-use the same nonces, even for a machine
that powercycles and has weak random at boot, due to the nonce being
part random and part counter, and each session starting with a new
random key following a (EC)DH (or KEM) exchange.

> RFC 9325 states: 
>
>     "While this problem has been fixed in TLS 1.3, which enforces a deterministic method
>     to generate nonces from record sequence numbers and shared secrets for all its AEAD
>     cipher suites (including AES-GCM), TLS 1.2 implementations could still choose their
>     own (potentially insecure) nonce generation methods.
> 
> Which is just another reason to request a proven way to generate GCM nonces that solves
> the problem in TLS 1.2 too, which is exactly what TLS-LTS is doing already.

But at what point do you stop backporting TLS 1.3 fixes into TLS 1.2,
instead of just switching to TLS 1.3?

Paul