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

[Eric Rescorla <[e-mail]>]

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

> On 11/08/2017 07:34 AM, Eric Rescorla wrote:
>
>
>
> 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.
>
>
> 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.


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

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


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