RFC 10015: Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2

Posted by Jimmc414 1 day ago

Counter80Comment22OpenOriginal

Comments

Comment by sidewndr46 1 day ago

Couldn't folks just use TLS 1.3?

Comment by onion2k 1 day ago

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.

Comment by Dylan16807 11 hours ago

Changing 1.2 also makes you upgrade if you want to take advantage of most changes. And 1.2 and 1.3 aren't super different, right? So if you've been willing to backport 1.2 changes, I'm not convinced backporting all of 1.3 is much harder. If you haven't backported anything, I don't think this news affects you.

Comment by charlieyu1 20 hours ago

TLS1.1 was a few years older than TLS1.2 and was deprecated a few years ago

Comment by mjevans 1 day ago

I think the entire point is so that many with devices that will never see updates can still continue to use those devices.

Comment by bigfatkitten 18 hours ago

Nobody is waiting on an RFC to make configuration changes to those devices to disable old cipher suites.

Comment by ImPostingOnHN 1 day ago

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?

Comment by 10000truths 1 day ago

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.

Comment by magicalhippo 1 day ago

> 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

Comment by bawolff 1 day ago

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.

Comment by jsiepkes 1 day ago

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

Comment by bawolff 1 day ago

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

Comment by chrisandchris 1 day ago

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.

Comment by 1 day ago

Comment by ImPostingOnHN 1 day ago

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

Comment by 0ckpuppet 1 day ago

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

Comment by nektro 1 day ago

better url https://datatracker.ietf.org/doc/html/rfc10015

Comment by mgr42 1 day ago

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.

Comment by throw-the-towel 12 hours ago

TIL: there's now more than 10,000 RFCs.

Comment by Sha1rholder 1 day ago

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.

Comment by PunchyHamster 1 day ago

Do you have slightest idea on how many devices that would brick

Comment by Gigachad 9 hours ago

They will get bricked sooner or later when some exploit rolls through. If these devices haven't been updated since 2018, they shouldn't be on the internet.

Comment by Sha1rholder 1 day ago

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

Comment by 1 day ago