On Mon, Nov 2, 2015 at 11:05 AM, Matt Corallo <[email protected]> wrote:
> 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? > Both tls-option and tcpcrypt send the client's DHE share along with the client's ACK and the server's DHE share in response. In both cases, the server can piggyback data on his share and the client can only send data upon receiving the server's share. I agree that this isn't optimal. My point is just that TLS and tcpcrypt have the same performance behavior here. Moving client pubkeys into SYN is slightly crazy, but would shave off a > RTT before client's first send. I believe we have definitively decided not to do this in an existing option. It's possible we would decide to do this via some of the option-extending mechanisms, but if you were to do this, you could equally well put the ClientHello in the SYN. -Ekr > > 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
