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

[Benjamin Kaduk <[e-mail]>]

On 11/08/2017 07:34 AM, Eric Rescorla wrote:
>
>
> On Wed, Nov 8, 2017 at 1:12 AM, Nikos Mavrogiannopoulos
> <[e-mail] <mailto:[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] <mailto:[e-mail]>>
>     > wrote:
>     > > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar <[e-mail]
>     <mailto:[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.
>

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

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

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

> -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
>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls