TLS 1.3 hasn't become TLS 1.4.
- Brian Couzens
- 5 hours ago
- 2 min read
It has become less tolerant of the past.
This month, the IETF published RFC 9846, which replaces RFC 8446 while keeping the protocol as TLS 1.3. On the surface, it looks like a minor revision.
It isn't.
One change stands out: Implementations MUST NOT negotiate TLS 1.0 or TLS 1.1.
Not "SHOULD NOT."
Not "avoid where possible."
MUST NOT.
That matters because we're reaching a tipping point.
For years, organisations carried obsolete cryptography because "it still works." Increasingly, it won't.
❌ Operating systems remove it.
❌ OpenSSL removes it.
❌ Browsers remove it.
❌ Cloud providers remove it.
❌ Now, the protocol specification itself forbids it.
This is why cryptographic debt is no longer just a confidentiality problem - it is becoming an AVAILABILITY problem.
If a legacy device, application, or embedded platform only speaks TLS 1.0 or TLS 1.1, the question is no longer:
"Is it secure enough?"
The question is becoming:
"Will anything still talk to it?"
👇 👇 👇
🤓 For the protocol nerds:
One interesting detail caught my eye.
Appendix E.2 still contains an example where a server might negotiate TLS 1.0 if the supported versions extension is absent. Yet Appendix E.5 now strictly states that TLS 1.0 and TLS 1.1 MUST NOT be negotiated for any reason (reflecting RFC 8996).
My reading: If supported versions is absent, a compliant implementation should attempt TLS 1.2 or immediately send a protocol version alert and terminate the handshake, rather than successfully falling back to 1.0.
I'd be interested to hear whether other implementers read it the same way, or whether the example simply survived the editorial update.
The broader lesson is clear regardless. Cryptographic debt doesn't just increase cyber risk anymore - it determines whether your systems stay online.
#CyberSecurity #TLS #Cryptography #NetworkSecurity #CyberResilience #PostQuantumCryptography #PQC #EnterpriseArchitecture #RiskManagement #CyberRisk
Comments