On Sat, Aug 2, 2014 at 5:44 PM, Eric Rescorla <[email protected]> wrote: > On Sat, Aug 2, 2014 at 5:27 PM, Watson Ladd <[email protected]> wrote: >> >> The third one has a major latency hit because TLS requires superfluous >> rounds of negotiation. > > > Hmm... Unless I am confused, here are the packet flows. > Best seen with fixed width fonts. > > The tcpcrypt proposal looks like this: > > Client Server > --------------------------------------------------------- > SYN/HELLO -> > <- SYN/ACK PKCONF, pub-cipher-list > INIT1, sym-cipher-list, N_C, pub-cipher, PK_C -> > <- ACK, INIT2, sym-cipher, KX_S > <- Data > Data -> > > > So the first time that anyone can send data is the server > on the fourth message. The client can send data on > receiving that message.
So it does: I was more focused on the cryptography when reading it. Of course, the optimal strategy is to do the key exchange in the initial round trip, ala CurveCP. Is there some reason why extra data cannot be added to the SYN packet? I'm aware of the charter, but I'd like to know why. (For those following along, the above comes from figure 1 of the tcpcrypt paper) > > > The TLS proposal looks like this (with TLS 1.2) > > Client Server > --------------------------------------------------------- > SYN/OPTION -> > <- SYN/ACK OPTION > ACK -> > ClientHello -> > <- ACK, ServerHello, etc. > ClientKeyExchange, etc. -> > Data -> > <- Finished > <- Data > Finished -> > > > The client can send at the same time here as with tcpcrypt > if he is doing False Start. The server can send one round trip > later, which is worse than tcpcrypt. Ah, so the difference is not as much as I thought it was. I think you got it right. > > > If you are doing TLS 1.3, then it looks like: > > Client Server > --------------------------------------------------------- > SYN/OPTION -> > <- SYN/ACK OPTION > ACK -> > ClientHello + CKE-> > <- ACK, ServerHello, etc. > <- Data > Finished -> > Data -> > > At which point the situation is the same as tcpcrypt. > > >> >> The promised >> improvements to TLS 1.3 don't help: they rely on session caches >> unnecessarily. > > > I'm not sure what you mean here. The 1RTT handshake for TLS 1.3 > does not require session caches, only a relatively restricted set of > ciphers/groups. It requires the client to guess correctly. If there are 3 groups, than 2/3s of the time it loses and falls back to a regular latency connection. This makes for interesting game theoretic behavior. > > -Ekr Sincerely, Watson Ladd _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
