On Mon, Nov 2, 2015 at 10:57 AM, Matt Corallo <[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]>> 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
