Re: [TLS] PR#1091: Changes to provide middlebox robustness

[Yuhong Bao <[e-mail]>]

The real question is if getting into an arms race with middleboxes is even a good idea IMO.

________________________________________
From: TLS <[e-mail]> on behalf of David Benjamin <[e-mail]>
Sent: Wednesday, November 22, 2017 5:02:15 AM
To: Tapio Sokura
Cc: [e-mail]
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

As a source of some of those numbers, someone interested in actually deploying TLS 1.3, and, most importantly, someone who would have to deal with the fallout of that deployment, I can unequivocally say those are not "very good" figures. They are completely implausible by orders of magnitude. TLS 1.3, the secure upgrade to TLS 1.2, is not even close to being deployable today.

Unchanged, deployment would require a unsecured version fallback, the same one that gave POODLE. An attacker could silently downgrade us to TLS 1.2. That ServerHello.random anti-downgrade signal would have been purely wishful thinking and never implemented. I think this would be a huge step back. A de facto fallback would also send the same signal as tweaking the protocol. There isn't enough incentive for middleboxes to ship updates or for administrators to deploy those updates when doing nothing works just fine. For 21 years, since SSL 3.0, we didn't really change TLS's handshake and left it all unencrypted. In retrospect, it's probably to be expected the network latched onto it. Ignoring the problem won't erase those 21 years.

These changes are certainly ugly, but they are only ugly. They have no impact on security, unlike the fallback which does. There is a complexity impact, but, having implemented it, the impact is actually quite small. Making the first server message more uniform between versions and HelloRetryRequest is even a small convenience.

This is indeed baggage, but that is not new. When I think of the consequences of buggy middleboxes, I am actually less concerned that our first roundtrip needs to look a little funny, and more that we are wasting three bytes in front of *every* record (PR762). That we have entirely lost TCP and my colleagues on QUIC needed to start over on UDP for improvements. That even then QUIC ran into ossification later on. That every protocol change is risky and requires endless experimentation. That the reality of engineering on the Internet appears to be: if it was observable over time, it has ossified.

I share the justified frustration with this picture, but it's reality. There are two questions now:

1) What we do need to do to deploy a change today? (Our handshake versioning joints have rusted shut, and we need to break them free.)
2) How do we avoid needing to do worse tomorrow? (We've got it moving again, and we want to keep it that way.)

PR1091 seems to answer (1). (2) is harder. We need to think about how to avoid ossification. Writing versioning invariants[*] clearly is an easy step, but text alone isn't enough. Reducing unencrypted portions is also obvious and valuable in itself, but TLS has a bootstrapping problem here. We also need to think more in the direction of GREASE, but perhaps further as GREASE itself only tried to prevent buggy endpoints.

This is a difficult question we won't fully explore immediately, and solving it is not going to magic away (1) anyway. So I think our first step is clear: get through the accumulated rust.

David

[*] TLS's versioning rules are quite restrictive. We promise you can parse newer ClientHellos. Everything after that is fair game to change. If you produced the ClientHello, you can reasonably assume the peer won't send you anything that will confuse you. If you are forwarding a ClientHello you did not produce, you MUST NOT process the response in any way. It will contain incompatible messages in the future. Alas, reality shows that the network did not observe these rules.

On Tue, Nov 21, 2017 at 9:41 PM Tapio Sokura <[e-mail]<mailto:[e-mail]>> wrote:
Hello,

On 6.11.2017 20:19, Eric Rescorla wrote:
> Once you do this, the middleboxes seem to mostly ignore everything
> after the CCS, so the rest of the handshake proceeds smoothly.
>
> This is all a bit nasty, but none of it changes the cryptographic
> computations or the state machine (because you just ignore CCS).

The discussion in Singapore on middlebox issues during the WG session
woke me up on this. I don't post much on this list, but here I have to
say that this dance to work around middleboxes looks seriously like
putting the cart before the horse.

I'm not arguing that the cryptographic properties/security of TLS 1.3 is
affected by these changes. I'm saying that this messing around with
making 1.3 look like 1.2 adds unnecessary complexity that will just hurt
everyone in the long run. In the short term you get a few % more
successful 1.3 handshakes, but once it's in the spec, it will bother
implementers for years to come.

Sometimes you have to let some things break to be able to move forward.
If over 90% (the figures presented in Singapore) of TLS 1.3 handshakes
already go through without 1.2 emulation / middlebox compensation in the
protocol, I find that a very good number for this point in time.

It's the middleboxes that should adapt to be 1.3 compatible, not the
other way around. This is not sending a good signal to the industry.

Sorry if I'm beating a dead horse (behind the cart). But my
interpretation of the comments made during the WG session indicate that
if there's consensus on incorporating these middlebox compatibility
changes, it's a very rough consensus.

   Tapio

_______________________________________________
TLS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tls