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

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 <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
> 