Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

rfc-editor.org

Post reply on HN
Print view View original

11–20 of 25 posts

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

#11

Post by 10000truths »

ImPostingOnHN wrote: post #7
mjevans wrote: post #6

Earlier quoted context omitted.

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

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.

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

#12

Post by jsiepkes »

bawolff wrote: post #8
sidewndr46 wrote: post #3

Couldn't folks just use TLS 1.3?

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.

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

#14

Post by chrisandchris »

jsiepkes wrote: post #12
bawolff wrote: post #8

Earlier quoted context omitted.

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…

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.

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

#15

Post by bawolff »

jsiepkes wrote: post #12
bawolff wrote: post #8

Earlier quoted context omitted.

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…

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

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

#16

Post by magicalhippo »

10000truths wrote: post #11
ImPostingOnHN wrote: post #7

Earlier quoted context omitted.

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

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

#17

Post by onion2k »

sidewndr46 wrote: post #3

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.

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

#18

Post by PunchyHamster »

Sha1rholder wrote: post #13

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

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

#20

Post by Sha1rholder »

PunchyHamster wrote: post #18
Sha1rholder wrote: post #13

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
Post reply on HN