Re: [tcpinc] Call for adoption of draft-rescorla-tcpinc-tls-option-05

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 <tcpinc@bluematt.me
> <mailto:tcpinc@bluematt.me>> 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 <tcpinc@bluematt.me <mailto:tcpinc@bluematt.me>
>     > <mailto:tcpinc@bluematt.me <mailto:tcpinc@bluematt.me>>> 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
> Tcpinc@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpinc
> 