Kyle Rose <[email protected]> writes: >> If we are going to add another round of exchanges anyway, though, why >> not do the tie-breaking there? We could keep the single b bit as is >> (for applications that want to work it out), and then add a >> variable-length tie-breaking phase. E.g., >> >> A->B: SYN ENO<Z, Y> >> B->A: SYN ENO<X, Y, Z> >> A->B: ACK ENO<Breaker 0x29892a863ce5> >> B->A: ACK ENO<Breaker 0xdb636b5918a2> > > Why not dump b entirely and just always require an extra round trip > for simultaneous open? It seems to be enough of an edge case that, > given the options, I'd rather not optimize for it (and also not spend > a disproportionate amount of time debating optimization of something > that is such a long-tail, and practically degenerate, use case).
There is one reason this isn't ideal (though I think it might still be workable), and that is that the first ACK packet might need to contain spec-specific information (like cipher suite preferences). If that information is in options only, then it doesn't consume sequence number space and now you have the problem of potentially needing to retransmit two ACKs for the other side's ISN. > IMHO, all applications should be able to benefit from TCPINC's > protection against passive eavesdropping without any changes. That's a perfectly valid position, and we can make it work. It will cost some complexity, though, so it would be nice to get clarity on whether this is also the preference of the whole working group. I wouldn't want to jump through hoops to make simultaneous open always work, then run into objections that it's too complicated or consumes too much option space. Note that yet another possibility is to delegate the choice of roles to the individual encryption specs. In the case of ECDHE, that's actually easy to do. But now the complexity of a fringe use case is bleeding into multiple documents. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
