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

[Nikos Mavrogiannopoulos <[e-mail]>]

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