On Sat, Aug 2, 2014 at 8:35 PM, Watson Ladd <[email protected]> wrote:
> 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. > The basic problem is that there isn't very much space in the TCP SYN options, so you need to put the key exchange in the TCP data (both TCPcrypt and TCP-use-TLS do this). However, it's possible (likely) that the server doesn't support TCPINC, so if you just unconditionally send crypto handshake material, you are going to cause failures on any server which is expecting application data instead. (See: http://tools.ietf.org/html/draft-rescorla-tcpinc-tls-option-00#section-1) Thus, the use of TCP options to confirm that both sides are prepared to do the handshake. Two notes about this: 1. This doesn't apply to settings in which the client knows that the server supports a secure channel, so in that case one might be able to use TCP Fast Open to send data in SYN. However, that's more applicable to HTTPS than to TCPINC which is designed to be opportunistic. 2. In Toronto there was discussion of some new techniques for extending the options space safely, in which case you would be able to optimistically send something in the first flight. See: http://www.ietf.org/id/draft-briscoe-tcpm-syn-op-sis-01.txt Others can talk more authoritatively about this than I can. > > 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. > The client is permitted to provide shares for multiple groups in its first flight. Obviously this doesn't scale to hundreds of groups, but if we provide recommendations for a small number, then we should be able to achieve fairly high success rates. Best, -Ekr
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
