Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

[Watson Ladd <[e-mail]>]

On Sun, Aug 23, 2015 at 9:38 AM, David Mazieres
<[e-mail]> wrote:
> Watson Ladd <[e-mail]> writes:
>
>> So 50% of the time, encryption fails between two parties both
>> supporting the spec, when using simultaneous open. Why not impose a
>> fixed ordering on all possible options and use the best mutually
>> supported option, aka versioning?
>
> No, encryption fails 100% of the time, because the b bit defaults to 0.
> As currently written, TCP-ENO requires application involvement to enable
> encryption under simultaneous open.

Ok, I got confused about what b was doing. I thought it was
disambiguating and picked randomly.

>
> The fixed ordering seems potentially harmful, because it might
> prioritize weak protocols over newer strong ones.  But maybe we could
> have some kind of combination, like assign all suboptions consecutive
> numbers in each SYN, and take set of suboptions which have the maximum
> value of the sum of the two numbers in the two SYN segments, and then
> apply the fixed ordering based on that?  (Maximum will favor
> variable-length options.)  We're definitely open to suggestions, but I
> worry this can get kind of complicated pretty quickly.

Think of this "fixed ordering" as versioning, like HTTP/0.9, 1.0, 1.1,
2.0, etc. The idea is that we'd only introduce new versions when we
knew they were stronger than the old ones.

>
>> My question is as follows: If we're willing to add half an RTT of
>> latency because we can't put key material in the first flight,
>> we can do the following exchange in the following manner
>> A->B "I can speak X,Y,Z"
>> B->A: "X, and here is my key share"
>> A->B: "here is my key share".
>
> That's certainly the kind of thing TCP-ENO is designed to allow.
> However, we don't completely rule out doing the key exchange in the SYN,
> as that may turn out to be a useful encryption spec down the line.
>
>> In the simultaneous case we can do: (using ; as sequencing mark)
>> A->B: "I speak X, Y, Z"
>> B->A: "I speak X,Y,Z";
>> A->B: "My key"
>> B->A "My key"
>>
>> A and B both know that X, Y, Z are ordered, and so can agree.
>> Now, both kinds of message are completely different, and so shouldn't
>> be variations on the same kind to avoid attacks based on confusing SYN
>> with SYN-ACK.
>
> Something like this might be viable.  Please spec it out in a bit more
> detail.

Will do sometime.
>
> David



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.