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

[Eric Rescorla <[e-mail]>]

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