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

From: Eric Rescorla <[email-masked]>
Date: Mon, 6 Nov 2017 10:19:01 -0800

https://github.com/tlswg/tls13-spec/pull/1091

As I mentioned a while back, we've been seeing evidence of middlebox
intolerance. I just posted PR 1091, which is based on a bunch of work
by the BoringSSL team and an original suggestion by Kyle Nekritz that
should significantly decrease the rate of these errors.

The general idea here is to make TLS 1.3 look more like TLS 1.2
resumption. The major changes are:

- Move version negotiation entirely into "supported_versions", and hence
  ServerHello.version == 0x0303 (TLS 1.2)
- Restore the missing session_id and compression fields in ServerHello
- The client sends a fake session_id and the server echoes it
- The server sends ChangeCipherSpec messages after
ServerHello/HelloRetryRequest
  (so that the middlebox ignores any "encrypted" data afterwards),
  and the client sends ChangeCipherSpec after ClientHello. Either
  side has to ignore ChangeCipherSpec during the handshake.
- Merge HRR and ServerHello into a single message with the semantics
  distinguished by a special ServerHello.Random value.
- Switch the record layer version to 0x0303 for post-ClientHello
  messages to match ServerHello.

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).
Several of the most unpleasant changes (sending fake session id and
sending ChangeCipherSpec), are only needed in compatibility mode,
and if you don't have to worry about middleboxes, you can just
omit them.

There are implementations of these changes (except for HRR) in both
BoringSSL and NSS, and Google has preliminary measurements with these
changes that show comparable error rates to TLS 1.2 (I expect them to
publish those shortly). We expect to have further measurements from
Chrome as well as from Firefox by the WG meeting.

Please take a look and hopefully we can close on this in Singapore.

-Ekr

---

From: Hubert Kario <[email-masked]>
Date: Tue, 07 Nov 2017 16:39:25 +0100

In general +1, I like to see TLS 1.3 deployed ASAP and making the spurious 
failures as rare as possible is a good way to make that happen.

that being said, I have few comments:

> - Restore the missing session_id and compression fields in ServerHello

less special cases in parser code - big +1

>   side has to ignore ChangeCipherSpec during the handshake.

That's the part I have a bit of a problem with.
If the CCS is necessary to make middleboxes work, and given that lack-of-CCS-
intolerance is not something that we can detect reliably (not in a way that 
can be simulated by an attacker), I think the CCS should be baked in the TLS 
1.3 as deep as it was baked into TLS 1.2.

That is, the standard should make it a mandatory message to send, fully parsed 
and validated, requiring aborting connection if it is received at any 
unexpected moment, in duplicate, omitted or malformed. Not only as part of the 
"compatibility mode".

> after the CCS, so the rest of the handshake proceeds smoothly.

So I have this crazy idea... What happens if the first message sent by client 
and server is the CCS?

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: David Benjamin <[email-masked]>
Date: Tue, 07 Nov 2017 16:59:21 +0000

> unexpected moment, in duplicate, omitted or malformed. Not only as part of

Having the receiver check would work for us (it's what our prototypes do).
And it's true that, were receivers to enforce this, it would be more likely
that implementations reliably work in these environments despite not
testing against them directly.

But we got feedback that this would be too much complexity for some folks.
Getting CCS/handshake synchronization right is a little subtle. And indeed,
I think CCS in TLS 1.2 was generally considered to have been a mistake.
Having the receiver ignore CCS also allows use cases without this kind of
baggage (consider QUIC's embedding of TLS 1.3) to unilaterally disable this
compatibility mode.

So I think I prefer the formulation in the PR.

> So I have this crazy idea... What happens if the first message sent by

We didn't test that variant, but we did try turning off the
client-generated session ID to see if that was necessary and it was if I
recall, the failure rate without that was comparable to draft-18 if not
higher. Additionally, we know that making the record layer say TLS 1.2 was
necessary once we made ServerHello.version say TLS 1.2. (We'd have had a
proposal for the working group sooner had we not missed that difference
first time around! :-( )

This makes me doubt just sticking a CCS in front would suffice. It suggests
that middleboxes are actually parsing out TLS more deeply than that. Which
is also what one can expect. I think the clear conclusion one can draw from
this issue and similar elsewhere is that every reliably observable property
of network traffic will, over time, become ossified. The Internet is very
change-averse, and TLS 1.2 gave it far too many bits to latch onto.

> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech
> Republic_______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Nov 2017 09:17:33 -0800

> 1.3 as deep as it was baked into TLS 1.2.

You don't detect it on an individualized basis. Rather, you measure whether
it's
necessary and if/when the necessary level of CCS becomes low enough, you
just stop sending it ever.

That is, the standard should make it a mandatory message to send, fully
> parsed

Yeah, I'm not enthusiastic about this. It's more stuff in the state machine
that
we hope to eventually eliminate. And as David says, it's totally unnecessary
for QUIC and DTLS

-Ekr

---

From: Hubert Kario <[email-masked]>
Date: Tue, 07 Nov 2017 19:11:17 +0100

> we hope to eventually eliminate. And as David says, it's totally unnecessary

what I was getting at is that if you want to be compatible with middleboxes, 
you send that CCS always, as you never know what thing will be between you and 
the peer

that means that all the large implementations will be sending them always

that means that new middleboxes will likely end up expecting it either way and 
existing ones won't have much incentive to update/fix

secondly, if we allow for sending CCS at any point, we will end up with the 
same bug as the Alert processing DoS there was in some implementations — one 
that allowed the peer to send unlimited amount of warning alerts

so even if we mark it as optional, I still think we should allow for it to be 
sent at only very specific moments and only once per side

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Nov 2017 10:31:23 -0800

On Tue, Nov 7, 2017 at 10:11 AM, Hubert Kario <[email-masked]> wrote:

> > > can be simulated by an attacker), I think the CCS should be baked in
> the
> > > TLS
> > > unexpected moment, in duplicate, omitted or malformed. Not only as
> part of
> > > the
> > > "compatibility mode".
> >

Given that this is (a) not encrypted (b) just discarded and (c) only
allowed during the handshake, this
doesn't seem like much of a DoS.

so even if we mark it as optional, I still think we should allow for it to
> be

I might be fine if it were required in this way, but not fine if it was
required that one enforce it.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 7 Nov 2017 20:23:49 +0000

I think Hubert makes excellent points.

“We can remove it when middleboxes aren’t a problem.”  Talk about aspirational (

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Nov 2017 09:02:36 +1100

> “We can remove it when middleboxes aren’t a problem.”  Talk about aspirational (

Given that we're almost there, and that only really browsers are
asking for these hacks, and that even some of those were almost ready
to ship without these hacks, I don't think that this is entirely
unrealistic as an aspiration.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 7 Nov 2017 23:41:51 +0000

➢ Given that we're almost there, and that only really browsers are
    asking for these hacks, and that even some of those were almost ready
    to ship without these hacks, I don't think that this is entirely
    unrealistic as an aspiration.
    
The Internet is more than just a couple of browser executables.

Does nobody think of the servers?

---

From: Yuhong Bao <[email-masked]>
Date: Tue, 7 Nov 2017 23:47:05 +0000

My favorite of course is introducing another version field in the ServerHello.
The same problem may repeat with future middleboxes.

________________________________________
From: TLS <[email-masked]> on behalf of Martin Thomson <[email-masked]>
Sent: Tuesday, November 7, 2017 2:02:36 PM
To: Salz, Rich
Cc: [email-masked]
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Nov 2017 15:57:08 -0800

> Does nobody think of the servers?

I do, but I don't really see how they're relevant for this question. Don't
the servers control the middleboxes they are behind?

-Ekr

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 7 Nov 2017 16:05:58 -0800

FWIW: In my experience middleboxes don't ossify based on what the spec
says, they ossify based on what they see on the wire. So, if common
implementations send CCS in a particular way, that's what will get --- and,
I'll argue, what has gotten --- ossified. I also agree with David and Eric
that compatibility mode shouldn't be required because QUIC doesn't need it.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 7 Nov 2017 16:25:48 -0800

On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar <[email-masked]> wrote:
> FWIW: In my experience middleboxes don't ossify based on what the spec says,
> they ossify based on what they see on the wire. So, if common

What does compatibility mode mean here? If we end up with having two
slightly different versions of TLS 1.3, one that looks more like TLS
1.2 and the other that does not, that doesn't seem like a good thing
to me.

My understanding is we already have ossification here and the debate
is what to do about it.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 8 Nov 2017 00:32:00 +0000

*   I do, but I don't really see how they're relevant for this question. Don't the servers control the middleboxes they are behind?

The smiley got lost.  But smiley isn’t quite the right emoticon either.  But to answer your question: no, the often don’t.  And it’s not just the middleboxes they are behind, but all those along the way.

To say that only browsers were asking for these hacks is also a little disingenuous.  It was a self-selected design group (to be charitable) that mostly worked by themselves without the whole WG being involved.  I’m glad we seem to be ending up with something that works, with the only thing being lost is some nerd esthetics, but let’s not forget the (to me, disappointing) way the whole thing went down: a collaboration among, and only among, Google, Mozilla, and Facebook.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Nov 2017 16:32:09 -0800

On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd <[email-masked]> wrote:

> says,
> What does compatibility mode mean here?

It means:

1. Send the fake session_id
2. Send a bunch of spurious CCS values.

If we end up with having two
> 1.2 and the other that does not, that doesn't seem like a good thing

Well, the idea is that this is a purely local decision by one side.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Nov 2017 11:41:15 +1100

> - The client sends a fake session_id and the server echoes it

One friendly amendment.  I think that we should insist (with a MUST)
that the server send CCS in the case that it receives a non-empty
session_id.  That gives clients the ability to insist on use of the
compatibility hack by a server.

Evidence shows that the server can't ensure that these (expletive
deleted) middleboxes don't mess with the connect unless the client
takes the steps that are outlined here, so it has no way to control
the use of the compatibility mode.  On the other hand, having the
server not send CCS when compatibility mode was needed would somewhat
undermine the client's efforts.

---

From: David Benjamin <[email-masked]>
Date: Wed, 08 Nov 2017 00:46:58 +0000

> Well, the idea is that this is a purely local decision by one side.

In particular, either "mode" leaves everything interoperable with
everything else, modulo middlebox misbehavior. The arrangement with CCS and
session_id is that the sender MAY send some random vestigial junk that the
receiver MUST ignore.

If you know your implementation lives in a context whether it doesn't
matter (QUIC, internal networks, a happy unrealistic future where networks
are made of unicorns and sunshine instead of middleboxes), you can avoid
sending the useless bits. Otherwise, you probably want to send it.

-Ekr

---

From: Yoav Nir <[email-masked]>
Date: Wed, 8 Nov 2017 08:50:31 +0200

> On 8 Nov 2017, at 2:32, Salz, Rich <[email-masked]> wrote:
> 
> I do, but I don't really see how they're relevant for this question. Don't the servers control the middleboxes they are behind?
>  
> The smiley got lost.  But smiley isn’t quite the right emoticon either. 

Maybe we need a resigned to the harsh reality emoticon. Oh wait, there is one [1]

> But to answer your question: no, the often don’t.  And it’s not just the middleboxes they are behind, but all those along the way.

The server-side middleboxes tend to be somewhat higher quality and get more regular updates. There are also fewer vendors, so the problem is more manageable.

> To say that only browsers were asking for these hacks is also a little disingenuous.  It was a self-selected design group (to be charitable) that mostly worked by themselves without the whole WG be…

Sure. Whatever applies to browsers applies to every app or library that uses a web service. So wget, cURL, any of the libraries for Java, whatever you call the libraries behind apps on the various mobile platforms. 

Yoav 

[1] https://www.urbandictionary.com/define.php?term=%F0%9F%98%8C

---

From: Yoav Nir <[email-masked]>
Date: Wed, 8 Nov 2017 08:52:23 +0200

> On 8 Nov 2017, at 2:25, Watson Ladd <[email-masked]> wrote:
> 

So you’d prefer that we just make this compatibility mode mandatory and always use it?  Despite the wasted bits, I think I’m with you on that.

Yoav

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 08 Nov 2017 10:12:09 +0100

> Well, the idea is that this is a purely local decision by one side.

Which increases the cost of TLS1.3 implementation and testing by
introducing different handshake state machines. Why not negotiate that
CCS addition with an extension and have it defined outside the TLS 1.3
spec? I understand the concerns of the browser "community" on being
100% backwards compatible with middle boxes, but the TLS1.3 standard is
more than just browsers. If 100% compatibility is required, there is a
very simple solution, use TLS 1.2.

regards,
Nikos

---

From: Hubert Kario <[email-masked]>
Date: Wed, 08 Nov 2017 13:01:37 +0100

On Tuesday, 7 November 2017 19:31:23 CET Eric Rescorla wrote:
> > > > In general +1, I like to see TLS 1.3 deployed ASAP and making the
> > 
> > spurious
> > 
> > > > > - Move version negotiation entirely into "supported_versions", and
> > 
> > hence
> > 
> > > > > - Restore the missing session_id and compression fields in
> > 
> > ServerHello
> > 
> > > You don't detect it on an individualized basis. Rather, you measure
> > 
> > whether
> > 
> > > it's
> > > Yeah, I'm not enthusiastic about this. It's more stuff in the state
> > 
> > machine
> > 
> > > that
> > > we hope to eventually eliminate. And as David says, it's totally
> > 
> > unnecessary
> > 
> > > for QUIC and DTLS
> > > 
> > > -Ekr
> > 

same could have been said about the warning alert handling, yet not even a 
10mbps flow could completely lock up 4 cores of a 3GHz Haswell CPU

yes, it all depended on how they were handled, but point still stands, 2 major 
implementations got it wrong

and given the information we were provided, I don't see a need to send 
multiple CCS messages

> required that one enforce it.

by "enforce" you mean "enforce CCS being sent" or "enforce that a single CCS 
was sent"?

And to answer the "Don't the servers control the middleboxes they are 
behind?":

No, they do not. And with B2B communication you never know what will be 
looking on-route on the connection. It's not inconceivable that even a 3rd 
party that is _not_ an ISP controls those middleboxes is involved. Let alone a 
different team that has different priorities that people that need that 
connection working.

In the web world you may think that we're already in the 2020s. In some 
enterprise networks people just recently noticed that we crossed to the new 
millennium.
(I'm of course joking, but the internal networks and Internet work on 
completely different timescales)

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Nov 2017 05:34:35 -0800

On Wed, Nov 8, 2017 at 1:12 AM, Nikos Mavrogiannopoulos <[email-masked]>
wrote:

> introducing different handshake state machines.

It doesn't introduce different handshake state machines, because you just
ignore the CCS.

> Why not negotiate that
> spec?

That actually does introduce different state machines.

-Ekr

I understand the concerns of the browser "community" on being

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Nov 2017 05:38:26 -0800

On Wed, Nov 8, 2017 at 4:01 AM, Hubert Kario <[email-masked]> wrote:

> > > > > intolerance is not something that we can detect reliably (not in a
> way
> > > > > that
> > > you send that CCS always, as you never know what thing will be between
> you
> > > and
> > > the peer
> > >
> > > that means that new middleboxes will likely end up expecting it either
> way
> > > and
> > > same bug as the Alert processing DoS there was in some implementations
> —
> > > one

We already have plenty of places where you can send an arbitrary number
of dummy messages, including the special case of padding-only packets which
we explicitly allow.

> multiple CCS messages

Yes I might be OK with forbidding it. My objection is rather to requiring
that receivers
check.

> by "enforce" you mean "enforce CCS being sent" or "enforce that a single

See above.

> completely different timescales)

They don't have to *control* those middleboxes. The point is that servers
have
a stable elationship with the middleboxes and therefore should be able to
determine
whether they can safely do TLS 1.3 or not and simply not negotiated.
Clients do
not have that luxury.

-Ekr

--

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 8 Nov 2017 07:54:59 -0600

On 11/08/2017 07:34 AM, Eric Rescorla wrote:
>
>
> On Wed, Nov 8, 2017 at 1:12 AM, Nikos Mavrogiannopoulos
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     > On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd
>     <[email-masked] <mailto:[email-masked]>>
>     > wrote:
>     > > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar <[email-masked]
>     <mailto:[email-masked]>>
>     > > wrote:
>     > > > FWIW: In my experience middleboxes don't ossify based on
>     what the
>     > > spec says,
>     > > > I'll argue, what has gotten --- ossified. I also agree with
>     David
>     > > and Eric

I am leery of things that we flat-out *ignore*, as that sort of thing
has a history of coming back to bite us.

> That actually does introduce different state machines.

True, but perhaps still worth thinking about.
In some sense, we might not even need an extension; we could take
Martin's idea and run with it -- server MUST send CCS if the client
sends a sessionID, and server MUST NOT send CCS if the client does not
send a sessionID.  This would still make the state machine bigger, but
avoids a fork that depends only on "what message do I receive here".  On
the other hand, it also places all the burden of deciding when to use
the compat scheme on the client, when people are making the case that
some servers, at least, have some sense of when they're behind a
relevant middlebox.  But I'm not entirely sure how convincing those
arguments have been, so far.

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Nov 2017 06:03:34 -0800

On Wed, Nov 8, 2017 at 5:54 AM, Benjamin Kaduk <[email-masked]> wrote:

> I am leery of things that we flat-out *ignore*, as that sort of thing has
> a history of coming back to bite us.
>

Well, I suppose that's possible, but given that this is in the plaintext
stream, it seems less concerning.

> In some sense, we might not even need an extension; we could take Martin's
> idea and run with it -- server MUST send CCS if the client sends a
> sessionID, and server MUST NOT send CCS if the client does not send a
> sessionID.  This would still make the state machine bigger, but avoids a
> fork that depends only on "what message do I receive here".  On the other
> hand, it also places all the burden of deciding when to use the compat
> scheme on the client, when people are making the case that some servers, at
> least, have some sense of when they're behind a relevant middlebox.  But
> I'm not entirely sure how convincing those arguments have been, so far.
>

Well, at some level the client has to make the initial decision because it
has to decide what to put in CH. If you replace your MUST NOT with a MAY,
then the server can decide for itself whether to send the CCS, and this
works well with "ignore"

-Ekr

> TLS mailing [email-masked]://www.ietf.org/mailman/listinfo/tls
>
>
>

---

From: Tapio Sokura <[email-masked]>
Date: Wed, 22 Nov 2017 04:40:43 +0200

Hello,

> 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

---

From: David Benjamin <[email-masked]>
Date: Wed, 22 Nov 2017 13:02:15 +0000

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.

---

From: Yuhong Bao <[email-masked]>
Date: Wed, 22 Nov 2017 17:52:48 +0000

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

________________________________________
From: TLS <[email-masked]> on behalf of David Benjamin <[email-masked]>
Sent: Wednesday, November 22, 2017 5:02:15 AM
To: Tapio Sokura
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

   Tapio

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 22 Nov 2017 10:14:50 -0800

> The real question is if getting into an arms race with middleboxes is even

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: Yuhong Bao <[email-masked]>
Date: Wed, 22 Nov 2017 18:16:29 +0000

The problem is not TLS 1.3, the problem is future versions of TLS.

________________________________________
From: Eric Rescorla <[email-masked]>
Sent: Wednesday, November 22, 2017 10:14:50 AM
To: Yuhong Bao
Cc: David Benjamin; Tapio Sokura; [email-masked]
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Wed, Nov 22, 2017 at 9:52 AM, Yuhong Bao <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> on behalf of David Benjamin <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, November 22, 2017 5:02:15 AM
To: Tapio Sokura
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

David

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

   Tapio

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Nov 2017 12:02:39 -0700

> The problem is not TLS 1.3, the problem is future versions of TLS.

Would you mind explaining that in more detail?

Peter

---

From: Yuhong Bao <[email-masked]>
Date: Wed, 22 Nov 2017 19:04:19 +0000

They are basically doing a supported_versions extension with only one entry in the ServerHello.
The problem with future middleboxes should be obvious.

________________________________________
From: Peter Saint-Andre <[email-masked]>
Sent: Wednesday, November 22, 2017 11:02:39 AM
To: Yuhong Bao; Eric Rescorla
Cc: [email-masked]; Tapio Sokura
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

Peter

---

From: Andrei Popov <[email-masked]>
Date: Wed, 22 Nov 2017 19:22:23 +0000

The idea was for the client to randomly add non-existent TLS versions to supported_versions.
Presumably, this will exercise the extensibility joint and prevent it from becoming unusable.

I'm not convinced this new approach will help, but we know the old one required fallbacks every time a new protocol version was introduced.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Yuhong Bao
Sent: Wednesday, November 22, 2017 11:04 AM
To: Peter Saint-Andre <[email-masked]>; Eric Rescorla <[email-masked]>
Cc: [email-masked]; Tapio Sokura <[email-masked]>
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

Peter

_______________________________________________
TLS mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C71d594d28d4241b8757f08d531dbdbb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636469742719473989&sdata=fCAZVB8XHK3IJQAoSf%2FUwSDlHYiy2tm0WBktCGS%2BPW8%3D&reserved=0

---

From: Yuhong Bao <[email-masked]>
Date: Fri, 24 Nov 2017 19:21:49 +0000

That only applies to the ClientHello.

________________________________________
From: Andrei Popov <[email-masked]>
Sent: Wednesday, November 22, 2017 11:22:23 AM
To: Yuhong Bao; Peter Saint-Andre; Eric Rescorla
Cc: [email-masked]; Tapio Sokura
Subject: RE: [TLS] PR#1091: Changes to provide middlebox robustness

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Yuhong Bao
Sent: Wednesday, November 22, 2017 11:04 AM
To: Peter Saint-Andre <[email-masked]>; Eric Rescorla <[email-masked]>
Cc: [email-masked]; Tapio Sokura <[email-masked]>
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

Peter