Bryan Ford <[email protected]> writes: >> And where did A get B's public key? By that point an asymmetric >> protocol would probably have allowed B to send data. Besides, why pay >> the price of two RSA decryptions when you only need one? > > A sends it to B in its INIT message (and vice versa). > > And yes, it costs two RSA decryptions instead of just one, but you > also get a potentially important benefit from this cost: namely the > ability to obtain PFS from RSA-based key exchange. In particular, > both the RSA key A sends to B and the key B sends to A could now be > short-term RSA public keys used only for key agreement, with the > users’ long-term (possibly RSA, possibly something-else) keys used > only for signing the session IDs generated via key agreement. Just > like ECDH achieves PFS, and just as symmetrical.
The PFS situation is identical whether you do one or two RSA decryptions. Either way you have to erase an RSA key when your connection ends or is rekeyed. Given the cost of generating RSA keys, it might be better to erase them every two minutes instead of exactly when the session ends. That's why the charter requires forward secrecy but not *perfect* forward secrecy. > All this is moot, of course, if we decide RSA isn’t really interesting > or necessary for tcpcrypt (which seems like a reasonable position). > But if we do want RSA, then I think RSA with PFS would definitely be > better in today’s world than RSA without PFS and I would argue worth > the cost, independent of whether it is embodied in a symmetric or > asymmetric protocol design. It's not RSA so much as any form of public-key encryption vs. just Diffie-Hellman key exchange. If we ever need to move to post-quantum crypto, it will most likely be with public key encryption (such as lattice-based ciphers) rather than Diffie-Hellman. Also, if we ever decide that elliptic curve cryptography is problematic and favor DH over Zp, then RSA may be competitive again. (I do think it more likely that RSA will fail before discrete log, but we shouldn't bet the future security of the Internet such conjectures.) > It is symmetrical in that each endpoint has the same set of choices > available to it and follows the same state machine (defined by Figure > 6 in RFC793). Well, in that sense ENO is symmetric as well, because you have the same state machine on both sides. > But given that TCP (as well as UDP) already have a long-established > tradition of role-symmetry in the transport protocol design, it just > feels cleaner to preserve it in a TCP extension like tcpcrypt. I reject the assertion that TCP has a long-established tradition of role-symmetry, except in the sense that ENO is symmetric (both hosts use the same state machine). How about this: Show me a tcpdump of a simultaneous open by an application that you did not write yourself, without transiting a firewall/NAT you specifically configured yourself for the purposes of the experiment, and then we'll talk. BUT, and this is the point, I think it's highly likely that even if you do demonstrate such an application, it will A) already be encrypting traffic, and/or B) provide a trivial way of assigning roles (e.g., the TCP stack might not know its own public IP address/port, but the application might, in which case you can just sort by <IP, port>). Given that there are very realistic scenarios in which future encryption specs will want to employ public-key encryption, and there are very real concerns that application-writers can misuse APIs, I don't think we can justify penalizing public-key encryption and complicating APIs without a concrete example of an application that would benefit. > Especially when preserving role-symmetry makes the protocol simpler > and cleaner, as I think it does. I also disagree about making the protocol simpler. Also, even if you do think the protocol is simpler, the API is more complicated, and that is likely to be the biggest source of errors. > OK, I see how this very RSA-encryption-specific optimization can shave > off a round-trip in the asymmetric case. But: > > (1) It clearly doesn’t provide PFS and doesn’t work for ECDH, which is > probably the current state-of-the-art we want to be focusing on > anyway. Whether or not it provides PFS just depends on when you erase the RSA key. Having two RSA decryptions won't help the PFS situation. There's an efficiency argument where DH can justify PFS, while with RSA you might want to reuse keys for two minutes. But that argument is entirely separate from the question of whether ENO is symmetric or not. > (2) If you want to shave off one round-trip, there are probably > cleaner and more general ways of doing it, e.g., the way TLS 1.3 is > doing it. Namely, the client caches the server’s PKB from the last > session, and starts the next session by optimistically assuming PKB > hasn’t changed, in which case the client send its (possibly fresh) PKA > and compute a shared secret using the server’s last-known PKB. This is could be problematic for server farms if SKB is secret. It also burns gratuitous CPU time. Plus, if you are really connecting to the same server, you should use session resumption. On the other hand, given that PKB is not used for security, how about picking some 512-bit modulus, publishing both the modulus and its factorization in the RFC, and saying all passive openers MUST use that one modulus (so only with two active openers would you not). Then you'll never miss in the cache! Now you could use different PKB on different servers, or use a modulus larger than 512 bits, but then you'd have more cache misses and more cost on the server for no benefit. Do you really still think yours is a simpler and cleaner design? > (3) If you really, really want to do the RSA-specific single-RTT > key-exchange hack above, you still CAN do it as a special-case > optimization within an otherwise-symmetrical version of the tcpcrypt > protocol. That is, on startup, IF the RSA suite was negotiated, then > look at the TCP-ENO tie-breaking bits and IF there’s a clear “winner”, > the A side initiates the abbreviated key-exchange protocol you > described above; otherwise both endpoints fall back on the more > general key-exchange. But frankly, I wouldn’t bother, given the other > alternatives available and the fact that we’re talking about RSA. We're talking about any key *exchange* (or transport), as opposed to key *agreement*. We might not be using RSA or ECDH in 30 years, but ideally ENO can still negotiate whatever ciphers people need. > OK - if you really care about hyper-optimizing RSA key exchange, I > won’t try to stop you, and that can be done in multiple ways as > discussed above. But designing the entire structure of tcpcrypt > around this one tiny optimization of a nearly-obsolete encryption > algorithm just doesn’t sound like a great tradeoff to me. :) Well, the 33x is for RSA. But if you look at some of the post-quantum algorithms on http://bench.cr.yp.to/results-encrypt.html, like ntruees787ep1, it's still up to a factor of two cheaper to encrypt than decrypt. And obviously that's in addition to the factor of two you are already paying for the gratuitous extra encryption/decryption, and the extra round-trip latency (because you wouldn't be doing key negotiation in the first place if you hit in the cache). It seems ridiculous to rule out efficient use of public key encryption, including post-quantum crypto, which may well be important someday, in favor of simultaneous open, which already basically works with ENO, would likely never be used with ENO anyway, and will grow even less relevant with IPv6 adoption. But as I said, cut and paste me a tcpdump and we'll talk. It may be that in a more specific context of an application that needs this we can find something that will satisfy you and not add gratuitous cost to the protocol and complexity to the API. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
