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

On Wed, Nov 22, 2017 at 9:52 AM, Yuhong Bao <yuhongbao_386@hotmail.com>
wrote:

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

I don't think of it this way. As David says, the problem here is that
middleboxes are misbehaving (i.e., not conforming to the TLS version
semantics) and aren't upgrading fast enough. If they actually were
upgrading quickly (what you would have to do to get in an arms race) then
they could also handle TLS 1.3 properly and we would be in far better shape.

-Ekr

>
> ________________________________________
> From: TLS <tls-bounces@ietf.org> on behalf of David Benjamin <
> davidben@chromium.org>
> Sent: Wednesday, November 22, 2017 5:02:15 AM
> To: Tapio Sokura
> Cc: tls@ietf.org
> 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 <tapio.sokura@iki.fi<mailto:
> tapio.sokura@iki.fi>> 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
> TLS@ietf.org<mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>