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?
Moving client pubkeys into SYN is slightly crazy, but would shave off a RTT before client's first send. On 11/02/15 01:59, Eric Rescorla wrote: > > > On Mon, Nov 2, 2015 at 10:57 AM, Matt Corallo <[email protected] > <mailto:[email protected]>> wrote: > > Indeed, it does effect both tls-option and tcpcrypt as written. However, > fixing it in tls-option appears to require departing from TLS, > > > Again, I don't believe that this is correct. The mode described here > is the basic operating mode for TLS 1.3 [0]. > > -Ekr > > [0] TLS 1.2 is equally fast to the client's first send (if you use False > Start) > but slower for the server's. > > > whereas > fixing it in tcpcrypt does not. > > On 11/02/15 01:42, Eric Rescorla wrote: > > On Mon, Nov 2, 2015 at 10:37 AM, Matt Corallo <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > > > I do not support adopting tcpinc-tls-option because: > > > > * Using TLS (even a limited set of allowed options) as the tcpinc > > mechanism loses the "defense in depth" property that tcpinc nicely > > provides for some applications. > > * I believe the extra round-trip for new connections to a new > server > > will significantly harm adoption of such a proposal. > > > > > > Can you elaborate on this? As indicated in the document, in TLS 1.3 > > the server can send his first byte upon receiving the client's first > > handshake message (in the ACK) and the client can send upon > > receiving the server's first handshake message (in the server's > > response to that message). I believe this shares the same latency > > characteristics as tcpcrypt. > > > > -Ekr > > > > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc > _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
