On Mon, Aug 24, 2015, at 02:33 PM, David Mazieres wrote: > Watson Ladd <watsonbl...@gmail.com> 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 _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
