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.
RFC 9851: TLS 1.2 is in Feature Freeze
11–20 of 30 posts
Re: RFC 9851: TLS 1.2 is in Feature Freeze
#12[dead]
Re: RFC 9851: TLS 1.2 is in Feature Freeze
#13[flagged]
Re: RFC 9851: TLS 1.2 is in Feature Freeze
#14I 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.
Re: RFC 9851: TLS 1.2 is in Feature Freeze
#15This 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.
Re: RFC 9851: TLS 1.2 is in Feature Freeze
#16This 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.
Re: RFC 9851: TLS 1.2 is in Feature Freeze
#17This 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.
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?
Re: RFC 9851: TLS 1.2 is in Feature Freeze
#18Earlier quoted context omitted.
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 i…
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.
Re: RFC 9851: TLS 1.2 is in Feature Freeze
#19This 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.
Well, for those of you who want to decrypt exchanges, plain-HTTP is best suited for you.
Assume your stance :)
Re: RFC 9851: TLS 1.2 is in Feature Freeze
#20This 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.
Isn't kind of the point of TLS that your communication doesn't get 'inspected'?