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

From: Matt Corallo <[email-masked]>
Date: Mon, 2 Nov 2015 01:37:30 +0000

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. While it seems
reasonably possible to fix this issue, doing so brings tls-option
further from the stated(?) goal of re-using TLS and all of its many
years of study. This would seem to largely defeat the purpose.

Matt

On 10/20/15 16:49, Mirja Kühlewind wrote:
> Hi all,
> 
> please indicate if you support adoption of
> draft-rescorla-tcpinc-tls-option-05 as a tcpinc working group item, or
> not, by
> 
>     Monday, Nov 2, 2015.
> 
> draft-rescorla-tcpinc-tls-option is one candidate for tcpinc where the
> first version of this draft was proposed more than a year ago. Verison
> -04 was release about three weeks ago and specifies the TLS 1.3 profile
> as well as the use of draft-rescorla-tcpinc-tls-option with tcp-eno.
> Since then this draft received a lot of discussion. The lasted update
> was provided yesterday, but only changes a few minor fixes.
> 
> Similar as before, if you do not support adoption of this document
> because you think it is not in scope for the wg or has fundamental
> technicals flaws and would therefore harm the goals of the wg, it would
> be great if you could given some reasoning/explanation with your response.
> 
> This is solely an adoption call for draft-rescorla-tcpinc-tls-option
> independent of any other documents. If you have a personal preference
> for a different approach that should not be a reason to reject this
> adoption. Forcing the wg to make a decision has not worked previously,
> and even though both proposed approaches have evolved, I do not see any
> indication that the wg is now ready to make a decision. The goal of this
> adoption call is to figure out if there is enough interest and energy to
> further follow the approach as outlined in
> draft-rescorla-tcpinc-tls-option-05.
> 
> This process may lead to the situation where the wg will adopt and work
> on two solution approaches. This does not mean that the wg will publish
> two (incompatible) approaches, as this would not fulfill our charter. If
> we end up adopting more than one approach, I currently see three way to
> proceed:
> 
> 1) Both approaches (naturally) converge into one approach.
> 
> 2) We work on both approaches to get them into a (similar) state where
> the wg is able to make a decision (and withdraw the other doc).
> 
> 3) We publish both approaches as different 'versions' of tcpinc that can
> be negotiated in the tcp-eno handshake, where at least one of them is
> mandatory to support/implement.
> 
> Thanks!
> Mirja
> 
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Nov 2015 10:42:19 +0900

On Mon, Nov 2, 2015 at 10:37 AM, Matt Corallo <[email-masked]> wrote:

> 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

---

From: Matt Corallo <[email-masked]>
Date: Mon, 2 Nov 2015 01:57:50 +0000

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-masked]
> <mailto:[email-masked]>> wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Nov 2015 10:59:59 +0900

On Mon, Nov 2, 2015 at 10:57 AM, Matt Corallo <[email-masked]> wrote:

> 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

---

From: Matt Corallo <[email-masked]>
Date: Mon, 2 Nov 2015 02:01:16 +0000

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.

---

From: Matt Corallo <[email-masked]>
Date: Mon, 2 Nov 2015 02:05:42 +0000

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 <[email-masked]
>     > On Mon, Nov 2, 2015 at 10:37 AM, Matt Corallo <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Nov 2015 11:09:21 +0900

> before session keys have been agreed upon?

Both tls-option and tcpcrypt send the client's DHE share along with
the client's ACK and the server's DHE share in response. In both
cases, the server can piggyback data on his share and the
client can only send data upon receiving the server's share.

I agree that this isn't optimal. My point is just that TLS and tcpcrypt
have the same performance behavior here.

> RTT before client's first send.

I believe we have definitively decided not to do this in an existing
option. It's possible we would decide to do this via some of the
option-extending mechanisms, but if you were to do this, you
could equally well put the ClientHello in the SYN.

-Ekr

> <mailto:[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 2 Nov 2015 13:07:05 +0900

On 21 October 2015 at 01:49, Mirja Kühlewind
<[email-masked]> wrote:
> draft-rescorla-tcpinc-tls-option-05 as a tcpinc working group item

Yeah, we should do this.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 2 Nov 2015 13:13:20 +0900

I support WG adoption of draft-rescorla-tcpinc-tls-option

> On Oct 21, 2015, at 1:49 AM, Mirja Kühlewind <[email-masked]> wrote:
> 
> Hi all,
> 
> draft-rescorla-tcpinc-tls-option-05 as a tcpinc working group item, or not, by
> 
> 	Monday, Nov 2, 2015.
> 
> draft-rescorla-tcpinc-tls-option is one candidate for tcpinc where the first version of this draft was proposed more than a year ago. Verison -04 was release about three weeks ago and specifies the TLS 1.3 profile as well as the use of draft-rescorla-tcpinc-tls-option with tcp-eno. Since then this draft received a lot of discussion. The lasted update was provided yesterday, but only changes a few minor fixes.
> 
> Similar as before, if you do not support adoption of this document because you think it is not in scope for the wg or has fundamental technicals flaws and would therefore harm the goals of the wg, it would be great if you could given some reasoning/explanation with your response.
> 
> This is solely an adoption call for draft-rescorla-tcpinc-tls-option independent of any other documents. If you have a personal preference for a different approach that should not be a reason to reject this adoption. Forcing the wg to make a decision has not worked previously, and even though both proposed approaches have evolved, I do not see any indication that the wg is now ready to make a decision. The goal of this adoption call is to figure out if there is enough interest and energy to further follow the approach as outlined in draft-rescorla-tcpinc-tls-option-05.
> 
> This process may lead to the situation where the wg will adopt and work on two solution approaches. This does not mean that the wg will publish two (incompatible) approaches, as this would not fulfill our charter. If we end up adopting more than one approach, I currently see three way to proceed:
> 
> 2) We work on both approaches to get them into a (similar) state where the wg is able to make a decision (and withdraw the other doc).
> 
> 3) We publish both approaches as different 'versions' of tcpinc that can be negotiated in the tcp-eno handshake, where at least one of them is mandatory to support/implement.
> 
> Thanks!
> Mirja
>

---

From: David Mazieres <[email-masked]>
Date: Mon, 02 Nov 2015 14:07:29 -0800

> before session keys have been agreed upon?

In tcpcrypt it's half an extra half round trip.  So for protocols where
the server speaks first (including only protocols like SMTP, NNTP, IMAP,
etc., where the server sends a greeting), there is no penalty.  But for
client-speaks-first protocols (such as HTTP), there is an extra round
trip.

> RTT before client's first send.

We'd all love to do that, but it is unlikely to happen before we get
large option support for SYNs.  So if you want to make this happen, your
best bet is to support something like tcpm-tcp-syn-ext-opt in the TCPM
working group and TCP-ENO in TCPINC.  The nice thing about TCP-ENO is
that it will naturally be able to take advantage of large SYN options as
soon as we have them.

David