On Sat, Aug 22, 2015 at 10:13 PM, David Mazieres <[email protected]> wrote: > Eric Rescorla <[email protected]> writes: > >> Review of draft-bittau-tcpinc-tcpeno-01 >> >> I have reviewed the -01 version of the ENO draft. This seems like a good >> general idea, but I have concerns about a number of the details. > > Thanks for going through in detail. I will respond point-by-point. > >> TECHNICAL >> S 3.0. >> The variable/non-variable encoding seems suboptimal and in particular >> the restriction that only one suboption can be variable length. What >> are we going to do if two specifications wish to have variable-length >> data in the SYN packets? The specification suggests that you should >> address this by having two ENO options but that seems clumsy. >> >> I would suggest instead that if the v bit is set the next byte be the >> length. This comes at the cost of one byte for settings where there is >> only one variable-length option but is more efficient when you >> want to have multiple variable-length options, since you don't need >> to repeat the kind byte. > > Our intent is to optimize for a future in which people only need one > variable-length option. For example, the SYN can list a bunch of > options, and then the SYN-ACK can pick one of them. The current design > saves one byte, which may be quite important. For instance, you can > just barely fit a P-256 or Curve25519 DH key exchange in TCP options > currently. If TCPINC is wildly successful, we can imagine a future spec > that does that and squeezes the 8 most popular SYN options into a single > byte or something. But if we waste even one more byte of option space, > we start closing a lot of doors along that front. > > That said, if you can provide an explicit example of why you might want > multiple variable-length suboptions, you could possibly convince us to > optimize for that case. > >> S 3.1. >> I am not convinced that a one-bit tiebreaker for simultaneous open >> is going to work. Experience with other protocols that have the >> problem of symmetry (e.g., ICE) is that this sort of thing results >> from confusion about which side is really "first". In that case, >> both sides will try to set the same "b" bit, and you will not break >> the symmetry. >> >> I believe we must either ignore simultaneous open or use a higher- >> entropy tiebreaker. > > A high-level question is whether we should completely abandon enabling > TCP?INC for simultaneous open. If we allow encryption under some > circumstances after simultaneous open, then the next question is how to > apportion responsibility for making it work. The high-entropy solution > says make it work with high probability, but at the cost of a lot more > option space. Since simultaneous open is kind of finicky anyway, > TCP-ENO took the approach of making applications responsible for working > out the roles. For example, one plausible approach is to set the 'b' > bit to 1 at the endpoint with the lowest (public-IP-address, > public-port-number) pair. That's obviously not information available to > TCP-ENO, which knows nothing of NATS, but is information available to an > application using STUN to broker simultaneous open. Perhaps we should > work out an example of simultaneous open in the API document.
Let's imagine the stupidest possible protocol: each party squeezes 32 bytes into each SYN, representing a Curve25519 public key, and we compute H(agreed key || lexographically least || lexographically greater) . This protocol supports simultaneous open. So why can't a more complicated protocol do the same? > > As it is, the b bit is an effort to find the knee in the cost-benefit > curve. I.e., is it worth 4+ bytes of option space to make > simultaneous open work? Hard to make that case. But is it worth one > *bit* not to shut the door completely? Quite possibly. > >> S 3.2. >> I am unclear on why the active opener needs to have an ENO segment >> in his first ACK. Can you explain? > > There are two reasons: > > 1. Given the prevalence of asymmetric routes, it's highly likely that > situations will arise where ENO options are stripped in one > direction but not the other. Therefore, both sides need to know > not only that the other endpoint supports ENO, but that the other > endpoint can receive ENO options. If you remove the requirement > for that ACK, a scenario such as Figure 7 would result in total > failure of the TCP connection, not just failure to encrypt. We > definitely want to avoid that. > > 2. Suboption data could involve parameters that are not universally > supported, in which case the active opener may which to disable > TCPINC based on the contents of the SYN-ACK segment. > >> This mechanism for negotiating mechanisms seems over-complex, what >> with A and B each providing lists and then choosing B's top >> preference. I would suggest instead that we simply have B choose out >> of A's list, as with ALPN. The document offers two reasons why this >> might not work, simultaneous open and inflexible implementations: If >> we resolve simultaneous open in the SYN exchange then this should work >> fine and the issue of implementation seems like a corner case. > > If by resolve simultaneous open you mean not support it, I agree. But > if you mean something else, then things can get tricky. I would > welcome a detailed design that works, but just saying "do something > like ALPN" is not enough detail to determine whether or not that > approach is viable. We'd need to see an "A -> B: ... B -> A: ..."- > style example with TCP flags. How often is simultaneous open used? Are there important applications we won't encrypt if we kill it? > > One big challenge of simultaneous open is that each side must > acknowledge the other side's SYN before seeing the other side's SYN-ACK. > Moreover, other than the SYN, you can't consume TCP sequence numbers > until you have definitively enabled or disabled TCPINC (and in the > former case negotiated an encryption spec). So whereas in a three-way > hand-shake, you can do: > > A -> B: SYN X > B -> A: SYN-ACK X' which depends on X > A -> B: ACK X'' which depends on X and X' and might disable TCPINC > > With simultaneous open, you have two pairs of messages sent in parallel: > > A -> B: SYN X > B -> A: SYN Y > > A -> B: SYN-ACK X' which depends on X and Y, but not X' or Y' > B -> A: SYN-ACK Y' which depends on X and Y, but not X' or Y' > > So in particular B does not have the opportunity to abort TCPINC in > response to X', but must decide it based on X and Y. That's why TCP-ENO > determines the spec based only on the first ENO option sent by each > side. But what do you need the other ones for in that case? If they just contain keying material, you probably want to specialize them to that case. -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
