On Sun, Aug 23, 2015 at 9:38 AM, David Mazieres <dm-list-tcpcr...@scs.stanford.edu> wrote: > Watson Ladd <watsonbl...@gmail.com> 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. _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
