Re: [tcpinc] Simultaneous open tie breaking

[David Mazieres <[e-mail]>]

Kyle Rose <[e-mail]> 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