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

RFC 9851: TLS 1.2 is in Feature Freeze

rfc-editor.org

Post reply on HN
Print view View original

21–30 of 30 posts

Re: RFC 9851: TLS 1.2 is in Feature Freeze

#21

Post by kijin »

ekr____ wrote: post #10
kijin wrote: post #4

Makes sense. Nobody wants to deal with "this user-agent claims to support TLS 1.2, except this extension that was added in 2026" anymore. If you're going to add or remove features, follow semver and bump that number.

This isn't quite how TLS feature negotiation works. Version numbers are negotiated and some of the parameters are carried along with the version, but a lot of functionality (e.g., cipher suites) is individually negotiated and to some extent orthogonal to the version. This of course also allows you to add new features to an existing version. What this draft is saying is that the IETF will not be adding new features ta…

A lot of attacks target that negotiation process, so it helps to minimize the number of parameters that need to be individually negotiated.

Re: RFC 9851: TLS 1.2 is in Feature Freeze

#22

Post by jeroenhd »

orlp wrote: post #20
MattPalmer1086 wrote: post #15

Earlier quoted context omitted.

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'?

There are valid edge cases where you want traffic to be encrypted on the internet, but be readable by some intercepting device under your control. Parental control software has done that for decades, and there are (in my opinion misguided) regulations in some sensitive industries that suggest having to store a decrypted traffic log.

Corporate MitM boxes are quite prevalent (they caused 5-10% of TLS 1.3 traffic to get dropped before they changed the protocol to fake TLS 1.2 session resumption) and when it comes to corporate-owned devices, that usually shouldn't pose too much of a privacy/security issue.

These setups were a lot easier back in the day when TLS let you set static keys, but you can still dump TLS key files and/or reject all non-proxied traffic with your MitM proxy if you want to do such a setup. It'll break loads of apps thanks to certificate pinning, but that's probably a good thing for such corporate networks.

Re: RFC 9851: TLS 1.2 is in Feature Freeze

#23

Post by DarkUranium »

tialaramex wrote: post #18
greggsy wrote: post #14

Earlier quoted context omitted.

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…

TIL that TLS (before 1.3) was designed by non-cryptographers. What the hell.

Re: RFC 9851: TLS 1.2 is in Feature Freeze

#24

Post by ivanr »

DarkUranium wrote: post #23
tialaramex wrote: post #18

Earlier quoted context omitted.

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…

TIL that TLS (before 1.3) was designed by non-cryptographers. What the hell.

You could argue that it was designed by one guy (Kipp Hickman) in three months:

https://www.feistyduck.com/newsletter/issue_131_the_legend_o...

Re: RFC 9851: TLS 1.2 is in Feature Freeze

#25

Post by MattPalmer1086 »

tialaramex wrote: post #16
MattPalmer1086 wrote: post #15

Earlier quoted context omitted.

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.

We use standard inspection techniques, not "cheap hacks", whatever they are.

What TLS 1.3 specifications for the required inspection infrastructure are you referring to?

Re: RFC 9851: TLS 1.2 is in Feature Freeze

#26

Post by MattPalmer1086 »

gdwatson wrote: post #17
MattPalmer1086 wrote: post #15

Earlier quoted context omitted.

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?

We operate Critical National Infrastucture for financial services. We have a lot of regulatory requirements that probably don't apply to most organisations.

Re: RFC 9851: TLS 1.2 is in Feature Freeze

#27

Post by tialaramex »

DarkUranium wrote: post #23
tialaramex wrote: post #18

Earlier quoted context omitted.

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…

TIL that TLS (before 1.3) was designed by non-cryptographers. What the hell.

I shouldn't undersell it quite as much as I did, the original SSL concept comes from Taher Elgamal who was ex-RSA and had published the cryptosystem named after him. So it's not really true that there aren't any cryptographers in the room. However more importantly what TLS (and earlier SSL) wants to do is extremely hard and once Javascript comes into the picture it's ludicrously harder for this to deliver security than basically any system ordinary people have used. Several "But obviously I would never do that" scenarios you'd learn about in a cryptography class like "What if your adversary can control part of the messages to be encrypted?" or "What if your adversary can force you to transmit the same exact message thousands or millions of times?" are routine requirements of security for HTTPS because of how the Web works.

And for SSL in particular why would math people (which is what cryptographers are) even be interested? 30+ Years Ago Tim's hypermedia system is just a toy and while its name, "World Wide Web" does sound like a big deal it's not actually important to your everyday life. If you live in a big city and it has a "web page" on Tim's system it's probably knocked together by some IT nerd who works for the city and the actual local government have no idea what a "web page" even is.

Probably by the time TLS 1.2 shipped, the relevant IETF Working Group (also named TLS) could have reached out and asked cryptography researchers to help first and got some engagement because it's obvious this is a big deal, but that didn't happen until TLS 1.3

Re: RFC 9851: TLS 1.2 is in Feature Freeze

#28

Post by tialaramex »

MattPalmer1086 wrote: post #25
tialaramex wrote: post #16

Earlier quoted context omitted.

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.

We use standard inspection techniques, not "cheap hacks", whatever they are. What TLS 1.3 specifications for the required inspection infrastructure are you referring to?

The TLS specifications have always told you that your options were

1. Retain each agreed session key for so long as you might wish to "inspect" that encrypted session. Now there's a signifier you're retaining for the specific session, which makes legal or moral considerations concrete in a way they were not for a vague "inspection" capability that applies for some undefined period over all traffic. The encrypted traffic itself can be retained arbitrarily because without those keys it's worthless.

2. Proxy all the traffic and decrypt/ encrypt at the proxy so that you can make transcripts of the plain traffic live. Everybody understands what these plain transcripts are now, if you're storing them, if some people have access, what that exactly means is obvious.

What you're probably doing, which is much cheaper but is a hack, is to rely on RSA key agreement and then copy the RSA private key to an "inspection" tool which of course can then decrypt absolutely anything, forever. This is obviously a terrible idea even though it was cheaper, which is why it went away in TLS 1.3

Re: RFC 9851: TLS 1.2 is in Feature Freeze

#29

Post by MattPalmer1086 »

tialaramex wrote: post #28
MattPalmer1086 wrote: post #25

Earlier quoted context omitted.

We use standard inspection techniques, not "cheap hacks", whatever they are. What TLS 1.3 specifications for the required inspection infrastructure are you referring to?

The TLS specifications have always told you that your options were 1. Retain each agreed session key for so long as you might wish to "inspect" that encrypted session. Now there's a signifier you're retaining for the specific session, which makes legal or moral considerations concrete in a way they were not for a vague "inspection" capability that applies for some undefined period over all traffic. The encrypted traf…

The TLS specifications say nothing about different traffic inspection techniques, or the relative merits of each.

What specifications are you talking about?

Re: RFC 9851: TLS 1.2 is in Feature Freeze

#30

Post by khivp »

MattPalmer1086 wrote: post #29
tialaramex wrote: post #28

Earlier quoted context omitted.

The TLS specifications have always told you that your options were 1. Retain each agreed session key for so long as you might wish to "inspect" that encrypted session. Now there's a signifier you're retaining for the specific session, which makes legal or moral considerations concrete in a way they were not for a vague "inspection" capability that applies for some undefined period over all traffic. The encrypted traf…

The TLS specifications say nothing about different traffic inspection techniques, or the relative merits of each. What specifications are you talking about?

In your previous comment you said you were using "standard inspection techniques".

Probably these standard inspection techniques you refer to have been updated to take TLS 1.3 into account, especially since TLS 1.3 has been out for a long time. Would you please be so nice as to point us to the standard you were referring to ?

Post reply on HN