Bryan Ford <[email protected]> writes: > So again, it feels to me like this all would strictly simplify the > protocol, make it more consistent with TCP’s symmetric design style, > and would make TCP simultaneous open “just work” with no extra > tie-breaking complexity or attendant risks of fail-open. Is there an > identifiable reason the current asymmetric behavior is necessary or > even advantageous?
Well, first, it's not at all clear that the new protocol will be simpler. For example, how does session resumption work with two session IDs? Having two session IDs could also make things a lot more complicated for applications. E.g., if you are storing session IDs in logs to compare after the fact, do you now have to store two session IDs? If you are using voice authentication, do you now have to read two large hex numbers over the phone? If you are using PAKE authentication as in the original tcpcrypt paper, do you have to authenticate two session IDs? Second, just because currently we are using ECDHE does not mean that we always will be. E.g., the NSA "suite B" has deprecated elliptic curve crypto for top secret documents. Who knows what this means--it could mean ECDHE is insecure, it could be some sort of weird reverse psychology, or it could be that we need all new curves. Nonetheless, if it turns out we want a TCPINC option to use RSA, then again there will be an inherent asymmetry in the key exchange. Third, the working group has been unable to identify a good application of simultaneous open that A) would benefit from tcpinc, and B) is harmed by the current b bit mechanism. Simultaneous open is much trickier to use in practice than in theory, with a result that it is usually a last choice anyway. Often the P2P apps doing it have their own encryption. And on top of that, often the connection has to be brokered in some way that makes it easy to assign the b bit. I've actually spoken to two different people who have basically told me the same thing, that they managed to get simultaneous open working but didn't end up using it in their product because it was too finicky. The only use case in the wild we have identified is ICE in firefox, and then it is only used if UDP does not work, and would want to disable tcpinc anyway. By contrast, there's plenty of RSA use in the wild. And someday we may want post-quantum options. So even if the current TCPINC drafts are exclusively ECDHE, I'd be uncomfortable forever ruling out public key encryption, whether by RSA or post-quantum lattice-based ciphers. Oh, and even if we move to DH over Zp, RSA becomes an attractive option for server performance. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
