Indeed, it does effect both tls-option and tcpcrypt as written. However, fixing it in tls-option appears to require departing from TLS, 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
