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

On Tue, Nov 7, 2017 at 7:32 PM Eric Rescorla <ekr@rtfm.com> wrote:

> On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
>
>> On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar <jri@google.com> 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.
>

In particular, either "mode" leaves everything interoperable with
everything else, modulo middlebox misbehavior. The arrangement with CCS and
session_id is that the sender MAY send some random vestigial junk that the
receiver MUST ignore.

If you know your implementation lives in a context whether it doesn't
matter (QUIC, internal networks, a happy unrealistic future where networks
are made of unicorns and sunshine instead of middleboxes), you can avoid
sending the useless bits. Otherwise, you probably want to send it.

-Ekr
>
>
>> My understanding is we already have ossification here and the debate
>> is what to do about it.
>>
>>
>> --
>> "Man is born free, but everywhere he is in chains".
>> --Rousseau.
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>