4 ms·
RFC 10015: Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2
- throw-the-towel 2mo agoTIL: there's now more than 10,000 RFCs.
- deleted 2mo ago[deleted]
- sidewndr46 2mo agoCouldn't folks just use TLS 1.3?
- ImPostingOnHN 2mo agobetter 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
- 0ckpuppet 2mo agoThese 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.)
- mjevans 2mo agoI think the entire point is so that many with devices that will never see updates can still continue to use those devices.
- ImPostingOnHN 2mo agowhat 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?
- 10000truths 2mo agoIf 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.
- magicalhippo 2mo 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 https://en.wikipedia.org/wiki/Downgrade_attack
- bigfatkitten 2mo agoNobody is waiting on an RFC to make configuration changes to those devices to disable old cipher suites.
- bawolff 2mo agoThey 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.
- jsiepkes 2mo 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.
- chrisandchris 2mo agoOr, 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.
- bawolff 2mo 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/ 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.
- deleted 2mo ago[deleted]
- onion2k 2mo agoThat 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.
- charlieyu1 2mo agoTLS1.1 was a few years older than TLS1.2 and was deprecated a few years ago
- Dylan16807 2mo agoChanging 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.
- nektro 2mo agobetter url https://datatracker.ietf.org/doc/html/rfc10015 https://datatracker.ietf.org/doc/html/rfc10015
- Sha1rholder 2mo agoI 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.
- PunchyHamster 2mo agoDo you have slightest idea on how many devices that would brick
- Sha1rholder 2mo agoMark 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
- Gigachad 2mo agoThey 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.
- mgr42 2mo agoInteresting, 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.