That question is essentially asked "Why can't we just upgrade all of our legacy systems that are more than 15 years old?" 15 years because anything running a network stack from 2011 probably doesn't support TLS1.3 unless the developers were moderately forward looking.
Most businesses have systems older than that. Most governments have systems twice as old as that. Upgrading things is hard, expensive, and in a lot of cases just not a priority. That's why old tech like TLS1.2 needs to remain secure.
If you control both the client and server, then yeah, you can use whatever protocol you want. Doesn't even need to be TLS, you could roll your own thing.
But if you only control one of the endpoints, then your ability to connect to a peer depends on what the peer thinks. And if the peer follows a standard that says your offered ciphersuites are all insecure, then you're out of luck.
True, but from a technical perspective "necessity" might be a bit of a strong term. For example as far as I know there aren't any Windows versions left that don't have support for TLS 1.2 but are still supported (i.e. not EOL). iirc Windows Server 2012 has support, but it's not enabled by default. So that's the closest to "unsupported" you get with Windows.
I think this is mostly because people are some what hesitant of enabling TLS 1.3. Because merely enabling TLS 1.3 along side TLS 1.2 can trigger latent bugs in clients.
> I think this is mostly because people are some what hesitant of enabling TLS 1.3. Because merely enabling TLS 1.3 along side TLS 1.2 can trigger latent bugs in clients.
I'm very doubtful. On the client side, people almost always go with defaults. On the server side, we are at ~75% market share for TLS1.3 https://www.ssllabs.com/ssl-pulse/
We are way past the point where people are afraid to enable tls1.3 because they think its buggy.
Or, just imagine that there are places in this world that still run old and outdated versions of something and upgrading is not an option because of "there's no money". We should not exclude all these places from all the internet just because of reasons.
better to break tons of existing installations and require confusing, arcane config file modifications just for folks to get things back to where they were before being broken
These prescriptions apply only to (D)TLS 1.2, since (D)TLS 1.0 and TLS 1.1 are deprecated by RFC 8996 and (D)TLS 1.3 either does not use the affected algorithms or does not share the relevant configuration options. (There is no DTLS version 1.1.)
Interesting, nice to see older TLS versions are getting updates like that. Official guidance is definitely beneficial to squeeze out more (safe) usage since it's so widespread.
I don't see much necessity. TLS1.3 is not something that hard or costly to support. I'd suggest just mark TLS1.2 as legacy and make some practical constraints to TLS1.3 applications/implementations to avoid replay attacks.
better url https://datatracker.ietf.org/doc/html/rfc10015
Couldn't folks just use TLS 1.3?
That question is essentially asked "Why can't we just upgrade all of our legacy systems that are more than 15 years old?" 15 years because anything running a network stack from 2011 probably doesn't support TLS1.3 unless the developers were moderately forward looking.
Most businesses have systems older than that. Most governments have systems twice as old as that. Upgrading things is hard, expensive, and in a lot of cases just not a priority. That's why old tech like TLS1.2 needs to remain secure.
TLS1.1 was a few years older than TLS1.2 and was deprecated a few years ago
I think the entire point is so that many with devices that will never see updates can still continue to use those devices.
Nobody is waiting on an RFC to make configuration changes to those devices to disable old cipher suites.
what stops folks from continuing to use them as-is, aside from this threat to break TLS 1.2 for them?
if a service runs TLS 1.2, and a client runs TLS 1.2, and they can talk to each other right now, why change the language?
if you released a thing, and people are choosing not to use it, is the right move really to enshittify their current choice to force them off it?
If you control both the client and server, then yeah, you can use whatever protocol you want. Doesn't even need to be TLS, you could roll your own thing.
But if you only control one of the endpoints, then your ability to connect to a peer depends on what the peer thinks. And if the peer follows a standard that says your offered ciphersuites are all insecure, then you're out of luck.
> And if the peer follows a standard that says your offered ciphersuites are all insecure, then you're out of luck.
Not even that. Many peers disconnect you if you offer any insecure cipher suite, in order to avoid downgrade attacks[1] presumably.
So if such a peer is updated to match this RFC, you'll have to follow the RFC too if you want to talk to them.
[1]: https://en.wikipedia.org/wiki/Downgrade_attack
They can and they should, but the world is not a perfect place, so backwards compatibility is neccessary.
So long as TLS 1.2 can still be used securely, its really not a big deal.
> so backwards compatibility is neccessary.
True, but from a technical perspective "necessity" might be a bit of a strong term. For example as far as I know there aren't any Windows versions left that don't have support for TLS 1.2 but are still supported (i.e. not EOL). iirc Windows Server 2012 has support, but it's not enabled by default. So that's the closest to "unsupported" you get with Windows.
I think this is mostly because people are some what hesitant of enabling TLS 1.3. Because merely enabling TLS 1.3 along side TLS 1.2 can trigger latent bugs in clients.
> I think this is mostly because people are some what hesitant of enabling TLS 1.3. Because merely enabling TLS 1.3 along side TLS 1.2 can trigger latent bugs in clients.
I'm very doubtful. On the client side, people almost always go with defaults. On the server side, we are at ~75% market share for TLS1.3 https://www.ssllabs.com/ssl-pulse/
We are way past the point where people are afraid to enable tls1.3 because they think its buggy.
Or, just imagine that there are places in this world that still run old and outdated versions of something and upgrading is not an option because of "there's no money". We should not exclude all these places from all the internet just because of reasons.
better to break tons of existing installations and require confusing, arcane config file modifications just for folks to get things back to where they were before being broken
These prescriptions apply only to (D)TLS 1.2, since (D)TLS 1.0 and TLS 1.1 are deprecated by RFC 8996 and (D)TLS 1.3 either does not use the affected algorithms or does not share the relevant configuration options. (There is no DTLS version 1.1.)
Interesting, nice to see older TLS versions are getting updates like that. Official guidance is definitely beneficial to squeeze out more (safe) usage since it's so widespread.
I don't see much necessity. TLS1.3 is not something that hard or costly to support. I'd suggest just mark TLS1.2 as legacy and make some practical constraints to TLS1.3 applications/implementations to avoid replay attacks.
Do you have slightest idea on how many devices that would brick
Mark TLS 1.2 as legacy means not recommend to use in the future, not abandoned or unsupported. It's not even a breaking change like this RFC