On Sat, Aug 2, 2014 at 10:26 PM, Eric Rescorla <[email protected]> wrote: > > > > 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.
The options are actually 44 bytes long. We would have to chuck out a lot of stuff to get 32 bytes to fit. It's not going to happen. Is data allowed in SYN? Could we have the SYN/ACK contain the server key and use bitmaps for the lists? I know 1RTT is possible: CurveCP and MinimaLT attain it. It would be a shame if we couldn't do the same. > > 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. So we tie on extension to another? To be clear, I like the deployability of the TLS over TCP option, and if we can't get better on latency, we might as well use it. (I'm a bit worried about implementation quality as a barrier to adoption: but this is solvable with some coding) > > >> >> > 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. Somehow I missed this mistake: the client does wasted work, potentially very expensive wasted work. But yes, it does reduce the game theory problem. Sincerely, Watson Ladd > > Best, > -Ekr > > _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
