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

[Eric Rescorla <[e-mail]>]

On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario <[e-mail]> wrote:

> 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:
>
> On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote:
> > 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
>
> less special cases in parser code - big +1
>
> > - 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.
>
> 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.
>

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
> 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".
>

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