3 ms·

RFC 9851: TLS 1.2 is in Feature Freeze

45 points by Jimmc414 2mo ago

richard_gg 2mo ago
[flagged]
mcpherrinm 2mo 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”.
kijin 2mo 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____ 2mo 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.
  - kijin 2mo ago
    A lot of attacks target that negotiation process, so it helps to minimize the number of parameters that need to be individually negotiated.
BobbyTables2 2mo 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.
- paseante 2mo ago
  [flagged]
- ekr____ 2mo 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 2mo 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 2mo 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.
pavon 2mo 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] [1]https://www.rfc-editor.org/rfc/rfc10015.html https://www.rfc-editor.org/rfc/rfc10015.html [2]https://news.ycombinator.com/item?id=49139711 https://news.ycombinator.com/item?id=49139711
fenestella 2mo ago
[flagged]
alex_akimov 2mo ago
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 2mo ago
  Except for those of us who have to do traffic inspection, which is blocked by TLS 1.3.
  - tialaramex 2mo 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.
    - MattPalmer1086 2mo ago
      We use standard inspection techniques, not "cheap hacks", whatever they are. What TLS 1.3 specifications for the required inspection infrastructure are you referring to?
      - tialaramex 2mo ago
        The TLS specifications have always told you that your options were 1. Retain each agreed session key for so long as you might wish to "inspect" that encrypted session. Now there's a signifier you're retaining for the specific session, which makes legal or moral considerations concrete in a way they were not for a vague "inspection" capability that applies for some undefined period over all traffic. The encrypted traffic itself can be retained arbitrarily because without those keys it's worthless. 2. Proxy all the traffic and decrypt/ encrypt at the proxy so that you can make transcripts of the plain traffic live. Everybody understands what these plain transcripts are now, if you're storing them, if some people have access, what that exactly means is obvious. What you're probably doing, which is much cheaper but is a hack, is to rely on RSA key agreement and then copy the RSA private key to an "inspection" tool which of course can then decrypt absolutely anything, forever. This is obviously a terrible idea even though it was cheaper, which is why it went away in TLS 1.3
glub103011 2mo ago
[dead]
nomadfreejobs 2mo ago
[flagged]

45 points by Jimmc414 2mo ago

[flagged]

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

kijin 2mo 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____ 2mo 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.
- kijin 2mo ago
  A lot of attacks target that negotiation process, so it helps to minimize the number of parameters that need to be individually negotiated.

BobbyTables2 2mo 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.

paseante 2mo ago
[flagged]
ekr____ 2mo 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 2mo 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 2mo 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.

pavon 2mo 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] [1]https://www.rfc-editor.org/rfc/rfc10015.html https://www.rfc-editor.org/rfc/rfc10015.html [2]https://news.ycombinator.com/item?id=49139711 https://news.ycombinator.com/item?id=49139711

fenestella 2mo ago

[flagged]

alex_akimov 2mo ago

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 2mo ago
Except for those of us who have to do traffic inspection, which is blocked by TLS 1.3.
- tialaramex 2mo 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.
  - MattPalmer1086 2mo ago
    We use standard inspection techniques, not "cheap hacks", whatever they are. What TLS 1.3 specifications for the required inspection infrastructure are you referring to?
    - tialaramex 2mo ago
      The TLS specifications have always told you that your options were 1. Retain each agreed session key for so long as you might wish to "inspect" that encrypted session. Now there's a signifier you're retaining for the specific session, which makes legal or moral considerations concrete in a way they were not for a vague "inspection" capability that applies for some undefined period over all traffic. The encrypted traffic itself can be retained arbitrarily because without those keys it's worthless. 2. Proxy all the traffic and decrypt/ encrypt at the proxy so that you can make transcripts of the plain traffic live. Everybody understands what these plain transcripts are now, if you're storing them, if some people have access, what that exactly means is obvious. What you're probably doing, which is much cheaper but is a hack, is to rely on RSA key agreement and then copy the RSA private key to an "inspection" tool which of course can then decrypt absolutely anything, forever. This is obviously a terrible idea even though it was cheaper, which is why it went away in TLS 1.3

glub103011 2mo ago

[dead]

nomadfreejobs 2mo ago

[flagged]