Matt Corallo <[email protected]> writes: > Am I incorrect in reading that both tls-option and tcpcrypt require a > full three-way-handshake, and then the client is unable to send data for > another round-trip as it must wait for another response from the server > before session keys have been agreed upon?
In tcpcrypt it's half an extra half round trip. So for protocols where the server speaks first (including only protocols like SMTP, NNTP, IMAP, etc., where the server sends a greeting), there is no penalty. But for client-speaks-first protocols (such as HTTP), there is an extra round trip. > Moving client pubkeys into SYN is slightly crazy, but would shave off a > RTT before client's first send. We'd all love to do that, but it is unlikely to happen before we get large option support for SYNs. So if you want to make this happen, your best bet is to support something like tcpm-tcp-syn-ext-opt in the TCPM working group and TCP-ENO in TCPINC. The nice thing about TCP-ENO is that it will naturally be able to take advantage of large SYN options as soon as we have them. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
