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

[David Mazieres <[e-mail]>]

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.

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.

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

David