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

[David Benjamin <[e-mail]>]

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]> 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]
> https://www.ietf.org/mailman/listinfo/tls
>
>