I should also mention this is due to the way tcp-eno is written, but my point is, even if tcp-eno were rewritten, tls-option would have to depart from tls further to fix it.
On 11/02/15 01:57, Matt Corallo wrote: > 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 > _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
