On Nov 7, 2015, at 3:05 PM, David Mazieres <[email protected]> wrote: > Bryan Ford <[email protected]> writes: >> Where would this create an extra round-trip? To me everything seems >> exactly the same in terms of round-trips. In the client/server >> “common case” scenario: >> >> 1. A (client) RSA-encrypts a secret S_A and sends it to B as part of >> its INIT packet. > > 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.
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.
>> And I think it’s more important for tcpcrypt not to break TCP’s model
>> precisely because tcpcrypt is (rightly) positioned as something
>> readily implementable in the kernel basically as an extension to the
>> TCP stack itself.
>
> But how is TCP's model symmetric? Simultaneous open is this weird
> fringe case that didn't even work until we had NATs and firewalls to
> suppress SYNs that would otherwise trigger RST packets. Even now it
> basically only works through particular kinds of NATs. We can barely
> seem to find any examples of its use in practice. Other than that, TCP
> is full of asymmetries on both the connection setup and shutdown.
> Someone with more historical perspective can correct me if I'm wrong,
> but it doesn't appear as though symmetry was a particular design goal of
> TCP.
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). It
might well be most commonly used in an asymmetrical fashion (with the “passive”
endpoint following a slightly different path through the TCP state machine than
the “active” endpoint), but it can also deal cleanly with the case where two
endpoints happen to express interest in talking to each other at about the same
time, forming a single connection with two active openers (the
simultaneous-open case). I always liked that property not just because it’s
(sometimes) useful for NAT traversal, but conceptually, e.g., for P2P protocols
where peers want to keep “a connection” open with each other for gossip or
whatnot (and would rather have just one symmetric connection, not one in each
direction). Admittedly this symmetry is not fundamentally essential and it’s
always possible to design applications or P2P protocols that build on
asymmetric transport (or encrypted-transport) protocols by adding appropriate
tie-breaking functionality. 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.
Especially when preserving role-symmetry makes the protocol simpler and
cleaner, as I think it does.
>> How to do that seems pretty clear to me, but perhaps I need to go do a
>> more thorough reading of the TCP-ENO draft and suggest specific text.
>> I’ll try to do that as soon as I have a moment.
>
> I think the best way to work through these things is with packet flow
> diagrams. For example, if your symmetric RSA example looks something
> like this:
>
> A -> B: SYN(ENO)
> B -> A: SYN-ACK(ENO)
> A -> B: (ENO) PKA
> B -> A: PKB, {NB}_PKA
> A -> B: {NA}_PKB
> A -> B: data
> B -> A: data
>
> Then it takes 2.5 round trips before B can send any data to A (using
> keys derived from NA, NB, PKA, PKB), vs. 1.5 in the simpler protocol
> where the session keys are derived from just PKA and NB (plus probably
> some other nonces not shown):
>
> A -> B: SYN(ENO)
> B -> A: SYN-ACK(ENO)
> A -> B: (ENO) PKA
> B -> A: {NB}_PKA
> B -> A: data
> A -> B: data
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.
(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 works equally well for either ECDH or RSA and allows for
forward-secrecy beyond PKA/PKB refresh epochs. (In the RSA case, the client
sends PKA,{NA}_PKB to the server in its first data round-trip, and can commence
sending encrypted payload data with it immediately.)
(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.
> The other major advantage of the second (asymmetric) diagram is that it
> supports very high connection rates at the passive opener, because with
> low exponents RSA encryption can be much faster than decryption. So the
> crypto for the symmetric RSA protocol isn't "just" twice as expensive on
> the server, but on my machine about 33x more expensive. The discrepancy
> grows linearly with modulus size, too, since decryption is O(n^3) and
> encryption O(n^2).
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. :)
Bryan
>
> David
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
