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

[Ralf Senderek]

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.

What TLS-LTS actually requires is that - if the tls_lts extension,
(which is already approved) is present in the Client Hello - then 
a hash of all messages leading up to the calculation of the master secret
will be used to generate the master secret in order to protect against the
use of manipulated handshake parameters.

That is a prudent way to reduce the attack surface not a change to TLS 1.2,
but to the way it is being implemented. 

And all the other requirements in -LTS have similar justifications.
 

[2] makes an interesting reference to RFC 9325 in which the preferred cipher
    suite is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 which every client should
    request first.

TLS-LTS limits the cipher suites (without PSK) to either
    TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
    or
    TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (with mandatory EtM)

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.
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.

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.

Ralf