On Sun, Aug 3, 2014 at 9:19 AM, Watson Ladd <[email protected]> wrote:
> 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? See note #1 below. Data is potentially allowed in the SYN [0], but if the server is expecting application data (i.e., it's a non-TCPINC-capable server) then it's going to generate a protocol error. That defeats being able to do opportunistic security. There seem to be two main options if you want opportunistic security - Use TCP options to negotiate the use of TCPINC before the client sends any TCPINC data. - Deliver the client's first flight of TCPINC data unconditionally but in some out of band fashion so that old servers don't choke. Note that I'm not saying that we couldn't get reduce the number of round-trips here, just that the backward compatibility requirement limits us in a way we wouldn't be limited if we were designing a de novo protocol with no such requirement. -Ekr [0] http://tools.ietf.org/html/draft-ietf-tcpm-fastopen-09
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
