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”.
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.
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.
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
In your previous comment you said you were using "standard inspection techniques".
Probably these standard inspection techniques you refer to have been updated to take TLS 1.3 into account, especially since TLS 1.3 has been out for a long time.
Would you please be so nice as to point us to the standard you were referring to ?
There are valid edge cases where you want traffic to be encrypted on the internet, but be readable by some intercepting device under your control. Parental control software has done that for decades, and there are (in my opinion misguided) regulations in some sensitive industries that suggest having to store a decrypted traffic log.
Corporate MitM boxes are quite prevalent (they caused 5-10% of TLS 1.3 traffic to get dropped before they changed the protocol to fake TLS 1.2 session resumption) and when it comes to corporate-owned devices, that usually shouldn't pose too much of a privacy/security issue.
These setups were a lot easier back in the day when TLS let you set static keys, but you can still dump TLS key files and/or reject all non-proxied traffic with your MitM proxy if you want to do such a setup. It'll break loads of apps thanks to certificate pinning, but that's probably a good thing for such corporate networks.
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?
We operate Critical National Infrastucture for financial services. We have a lot of regulatory requirements that probably don't apply to most organisations.
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.
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.
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.
I shouldn't undersell it quite as much as I did, the original SSL concept comes from Taher Elgamal who was ex-RSA and had published the cryptosystem named after him. So it's not really true that there aren't any cryptographers in the room. However more importantly what TLS (and earlier SSL) wants to do is extremely hard and once Javascript comes into the picture it's ludicrously harder for this to deliver security than basically any system ordinary people have used. Several "But obviously I would never do that" scenarios you'd learn about in a cryptography class like "What if your adversary can control part of the messages to be encrypted?" or "What if your adversary can force you to transmit the same exact message thousands or millions of times?" are routine requirements of security for HTTPS because of how the Web works.
And for SSL in particular why would math people (which is what cryptographers are) even be interested? 30+ Years Ago Tim's hypermedia system is just a toy and while its name, "World Wide Web" does sound like a big deal it's not actually important to your everyday life. If you live in a big city and it has a "web page" on Tim's system it's probably knocked together by some IT nerd who works for the city and the actual local government have no idea what a "web page" even is.
Probably by the time TLS 1.2 shipped, the relevant IETF Working Group (also named TLS) could have reached out and asked cryptography researchers to help first and got some engagement because it's obvious this is a big deal, but that didn't happen until TLS 1.3
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.
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”.
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
[2]https://news.ycombinator.com/item?id=49139711
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.
Except for those of us who have to do traffic inspection, which is blocked by TLS 1.3.
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.
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?
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
The TLS specifications say nothing about different traffic inspection techniques, or the relative merits of each.
What specifications are you talking about?
In your previous comment you said you were using "standard inspection techniques".
Probably these standard inspection techniques you refer to have been updated to take TLS 1.3 into account, especially since TLS 1.3 has been out for a long time. Would you please be so nice as to point us to the standard you were referring to ?
Isn't kind of the point of TLS that your communication doesn't get 'inspected'?
There are valid edge cases where you want traffic to be encrypted on the internet, but be readable by some intercepting device under your control. Parental control software has done that for decades, and there are (in my opinion misguided) regulations in some sensitive industries that suggest having to store a decrypted traffic log.
Corporate MitM boxes are quite prevalent (they caused 5-10% of TLS 1.3 traffic to get dropped before they changed the protocol to fake TLS 1.2 session resumption) and when it comes to corporate-owned devices, that usually shouldn't pose too much of a privacy/security issue.
These setups were a lot easier back in the day when TLS let you set static keys, but you can still dump TLS key files and/or reject all non-proxied traffic with your MitM proxy if you want to do such a setup. It'll break loads of apps thanks to certificate pinning, but that's probably a good thing for such corporate networks.
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?
We operate Critical National Infrastucture for financial services. We have a lot of regulatory requirements that probably don't apply to most organisations.
Well, for those of you who want to decrypt exchanges, plain-HTTP is best suited for you.
Assume your stance :)
I don’t get it. Were there revisions or optional features of v1.2?
I thought the 1.2 spec was the frozen spec.
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.
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.
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.
TIL that TLS (before 1.3) was designed by non-cryptographers. What the hell.
I shouldn't undersell it quite as much as I did, the original SSL concept comes from Taher Elgamal who was ex-RSA and had published the cryptosystem named after him. So it's not really true that there aren't any cryptographers in the room. However more importantly what TLS (and earlier SSL) wants to do is extremely hard and once Javascript comes into the picture it's ludicrously harder for this to deliver security than basically any system ordinary people have used. Several "But obviously I would never do that" scenarios you'd learn about in a cryptography class like "What if your adversary can control part of the messages to be encrypted?" or "What if your adversary can force you to transmit the same exact message thousands or millions of times?" are routine requirements of security for HTTPS because of how the Web works.
And for SSL in particular why would math people (which is what cryptographers are) even be interested? 30+ Years Ago Tim's hypermedia system is just a toy and while its name, "World Wide Web" does sound like a big deal it's not actually important to your everyday life. If you live in a big city and it has a "web page" on Tim's system it's probably knocked together by some IT nerd who works for the city and the actual local government have no idea what a "web page" even is.
Probably by the time TLS 1.2 shipped, the relevant IETF Working Group (also named TLS) could have reached out and asked cryptography researchers to help first and got some engagement because it's obvious this is a big deal, but that didn't happen until TLS 1.3
You could argue that it was designed by one guy (Kipp Hickman) in three months:
https://www.feistyduck.com/newsletter/issue_131_the_legend_o...
[flagged]
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.
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.
A lot of attacks target that negotiation process, so it helps to minimize the number of parameters that need to be individually negotiated.
[flagged]
[flagged]
[dead]
[flagged]