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

[Eric Rescorla <[e-mail]>]

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

> On Tue, 2017-11-07 at 16:32 -0800, Eric Rescorla wrote:
> >
> >
> > On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd <[e-mail]>
> > wrote:
> > > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar <[e-mail]>
> > > 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
> > > > 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.
> > >
> > > 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
> > > 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.
> >
> > 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.


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



> Why not negotiate that
> CCS addition with an extension and have it defined outside the TLS 1.3
> spec?


That actually does introduce different state machines.

-Ekr

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