Rendered at 09:14:04 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
mcpherrinm 7 hours ago [-]
This shouldn’t be too much of a surprise, as TLS 1.3 has been out for many years and is widely adopted.
I haven’t paid too much attention to the TLS WG lately (for obvious reasons if you look at their mailing list), but I assume this is mostly a “if you want Post-Quantum cryptography, you need 1.3”.
pavon 6 hours ago [-]
I assume this is in contest with RFC10015 which proposes "Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2"[1]. Both are Proposed Standards submitted in July, by the same author. HN discussion[2]
This makes sense, especially given that everyone should be already migrating to TLS 1.3 as fast as possible. However, as we see from past industry examples, migrations to every new standard often take decades.... Maybe the recent security incidents with AI will accelerate TLS 1.3 adoption everywhere.
MattPalmer1086 1 hours ago [-]
Except for those of us who have to do traffic inspection, which is blocked by TLS 1.3.
tialaramex 51 minutes ago [-]
No.
If you want to do "inspection" with TLS 1.3 you need to actually build the infrastructure these TLS specifications have always told you to use, rather than a cheap hack where too bad the users' security was destroyed but at least your "inspection" was cheaper.
orlp 31 minutes ago [-]
Isn't kind of the point of TLS that your communication doesn't get 'inspected'?
gdwatson 44 minutes ago [-]
Deliberately so, and for an Internet standard correctly so. I know there is a long tail of environments, so I am curious. What's your environment like that you need traffic inspection but don't have full control of the clients?
JackSlateur 35 minutes ago [-]
Well, for those of you who want to decrypt exchanges, plain-HTTP is best suited for you.
Assume your stance :)
BobbyTables2 7 hours ago [-]
I don’t get it. Were there revisions or optional features of v1.2?
I thought the 1.2 spec was the frozen spec.
ekr____ 6 hours ago [-]
TLS is an extensible protocol. For instance, you can add new key establishment algorithms or cipher suites. What this specification is saying is that the IETF will not be publishing such extensions for TLS 1.2. For example, they will not be adding post-quantum key establishment.
greggsy 2 hours ago [-]
PQE is probably a good catalyst for change here. It could easily have become a ‘forever protocol’ like IPv4, but there’s a point where maintaining two competing standards becomes onerous, especially when the newer one has wider support, fewer ‘bad’ configuration options to get wrong (can’t say the same for IPv6 unfortunately).
Quantum resistance has also become a requirement in many regulatory environments, so this is a good opportunity to force that transition towards TLSv1.3. They have been nudging for some time, but 1.2 is still somehow the default in a lot of products.
tialaramex 39 minutes ago [-]
TLS 1.2 is known to have a lot of problems that wouldn't in practice be fixed by extensions except in the sense that TLS 1.3, for compatibility reasons, pretends to be a single "extension" to TLS 1.2 which I've characterized as "Fly-casual-this-is-TLS-1.3" and is not in reality an extension at all.
Among the worst problems is that both cheap "We'll talk again soon" key agreement avoidance optimisations in TLS 1.2 are effectively security holes by design. However generally the problem in SSL and TLS up to 1.2 was that they're designed by software engineers who know some cryptography and then some real cryptographers are brought in at the end to check it works. Like having the civil engineer give your bridge design a once over after some non-engineers have made the plans it's just too late to do a proper job. "This bridge will definitely collapse and kill everyone" is avoidable, but "I dunno, this seems like a bad idea, I wouldn't do it that way" just gets ignored as too late.
TLS 1.3 is the first version where cryptographers had actually proved it works before the protocol was set in stone. Now, the proof has a small misunderstanding (called the "Selfie" attack, it's not relevant to a web browser but people doing low-level peer-to-peer type stuff need to understand it before using TLS at all) but having it at all was a huge difference.
paseante 6 hours ago [-]
[flagged]
kijin 7 hours ago [-]
Makes sense. Nobody wants to deal with "this user-agent claims to support TLS 1.2, except this extension that was added in 2026" anymore.
If you're going to add or remove features, follow semver and bump that number.
ekr____ 5 hours ago [-]
This isn't quite how TLS feature negotiation works.
Version numbers are negotiated and some of the parameters are carried along with the version, but a lot of functionality (e.g., cipher suites) is individually negotiated and to some extent orthogonal to the version. This of course also allows you to add new features to an existing version.
What this draft is saying is that the IETF will not be adding new features targeted at TLS 1.2.
I haven’t paid too much attention to the TLS WG lately (for obvious reasons if you look at their mailing list), but I assume this is mostly a “if you want Post-Quantum cryptography, you need 1.3”.
[1]https://www.rfc-editor.org/rfc/rfc10015.html
[2]https://news.ycombinator.com/item?id=49139711
If you want to do "inspection" with TLS 1.3 you need to actually build the infrastructure these TLS specifications have always told you to use, rather than a cheap hack where too bad the users' security was destroyed but at least your "inspection" was cheaper.
Assume your stance :)
I thought the 1.2 spec was the frozen spec.
Quantum resistance has also become a requirement in many regulatory environments, so this is a good opportunity to force that transition towards TLSv1.3. They have been nudging for some time, but 1.2 is still somehow the default in a lot of products.
Among the worst problems is that both cheap "We'll talk again soon" key agreement avoidance optimisations in TLS 1.2 are effectively security holes by design. However generally the problem in SSL and TLS up to 1.2 was that they're designed by software engineers who know some cryptography and then some real cryptographers are brought in at the end to check it works. Like having the civil engineer give your bridge design a once over after some non-engineers have made the plans it's just too late to do a proper job. "This bridge will definitely collapse and kill everyone" is avoidable, but "I dunno, this seems like a bad idea, I wouldn't do it that way" just gets ignored as too late.
TLS 1.3 is the first version where cryptographers had actually proved it works before the protocol was set in stone. Now, the proof has a small misunderstanding (called the "Selfie" attack, it's not relevant to a web browser but people doing low-level peer-to-peer type stuff need to understand it before using TLS at all) but having it at all was a huge difference.
If you're going to add or remove features, follow semver and bump that number.
Version numbers are negotiated and some of the parameters are carried along with the version, but a lot of functionality (e.g., cipher suites) is individually negotiated and to some extent orthogonal to the version. This of course also allows you to add new features to an existing version.
What this draft is saying is that the IETF will not be adding new features targeted at TLS 1.2.