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

[Mark Handley <[e-mail]>]

On Mon, Aug 24, 2015, at 02:33 PM, David Mazieres wrote:
> Watson Ladd <[e-mail]> writes:

> > The problem is with the existence of sites where only one algorithm
> > must be used, and the OS is configured accordingly.
> 
> Hard-coding global cipher priority is likely to exacerbate this problem.
> If the only way to prefer GOST is to disable AES entirely, well, then
> Russian institutions will disable AES.

[just back from vacation, and trying to catch up]

Surely we don't need to hard-code cipher priority to choose a mutually
acceptable cipher in the case of simultaneous open.

For example, suppose we have:

A->B SYN ENO(X,Y,Z) 
B->A SYN ENO(Z,Y,X)

You eliminate any not supported by both parties, rank the remaining
options from each message, square the ranks, and sum the squares:
X: 1^2 + 3^2 = 10  (X is rank 1 from A's SYN and rank 3 from B's SYN).
Y: 2^2 + 2^2 = 8
Z: 3^2 + 1^2 = 10

Both choose Y because the sum (8) is the lowest, and send the key
material for Y in the ACK.  

The rationale is both A and B had reasons for their ranking, and with
simultaneous open, you're trying to find a mutually acceptable
compromise.  The squaring does this.  If there's still a tie, it doesn't
really matter which you choose, and no good way to disambiguate, so hash
both option lists and choose the prefered tied option from the list with
the lower hash.


For non-simultaneous open, allowing the passive opener to choose seems
to make most sense.  Simultaneous open is a corner case, and I don't
think it's worth wasting bytes to try to do any better than achieve a
reasonably mutually acceptable compromose.

Mark