Subject: [tcpinc] TCP-ENO: Encryption Negotiation Option

From: David Mazieres <[email-masked]>
Date: Thu, 30 Jul 2015 15:26:03 -0700

The tcpcrypt team is as committed as ever to contributing to continued
improvement, standardization, and deployment of tcpcrypt should the
draft be adopted by the TCPINC working group.

However, we have decided that it may be preferable to specify tcpcrypt
in two separate documents:  one concerning the negotiation of
encryption, the other concerning key agreement and data transmission
formats.

The downside of splitting the draft is that the previous document was
already in good shape and has essentially been more-or-less
"ready-to-go" for over a year (with periodic revisions to meet working
group decisions).  If the working group decides to adopt the existing
tcpcrypt document tomorrow, we believe it would make a great starting
point for an RFC.  Of course, once the working group assumes ownership
of the document, we anticipate continued improvements, which may
ultimately include splitting the document anyway.

The upside of splitting the draft is twofold.  First, throughout the
TCPINC process, we have heard of ongoing standardization efforts (such
as large options) that could benefit TCPINC.  Unfortunately, those
technologies are not yet ready for deployment.  Separating negotiation
from encryption leaves us maximum flexibility to evolve TCPINC to
exploit future TCP enhancements in a backward-compatible way.

Second, we believe that the TCPINC working group has considerable
agreement on what needs to happen for encryption negotiation, and that
most of the disagreement has revolved around key agreement and wire
formats.  It is our hope that if the working group can agree on a
negotiation mechanism, this will constitute concrete progress that can
inject momentum into the whole TCPINC standardization process.

The new draft, called draft-bittau-tcpinc-tcpeno-00 (TCP-ENO), is
available at the following URL:

        https://datatracker.ietf.org/doc/draft-bittau-tcpinc-tcpeno/

Unless people either strenuously object to this draft (or kill
tcpcrypt), we will shortly release an revised tcpcrypt draft built on
TCP-ENO.  We encourage everyone who has not yet voted on this list to
vote to adopt tcpcrypt tomorrow.  But now you can additionally vote to
adopt TCP-ENO.  Even if you voted for TCP-use-TLS, I would encourage you
to consider voting for TCP-ENO as well, as those two drafts could also
be made to work together.

My vote is to adopt both TCP-ENO and tcpcrypt, which together provide an
obvious path for harmonization.

David

---

From: Joe Touch <[email-masked]>
Date: Thu, 30 Jul 2015 15:40:45 -0700

On 7/30/2015 3:26 PM, David Mazieres wrote:
...
>         https://datatracker.ietf.org/doc/draft-bittau-tcpinc-tcpeno/

FWIW, this draft could benefit from early deployment experience using a
TCP "ExID" (RFC6994).

Joe

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 30 Jul 2015 20:20:19 -0400

>         https://datatracker.ietf.org/doc/draft-bittau-tcpinc-tcpeno/

I like this proposal and i think it should be adopted by the WG.  It
represents exactly the kind of convergence work people were arguing for
at the recent meeting.

Can folks from the tcp-use-tls draft comment on whether they think they
could use this mechanism (or something we evolve from it as a group)?

David and Andrea, you should add a normative reference to RFC 2119, and
i think maybe you should move the tcpcrypt reference from normative to
informative, since the dependency goes the other way around (tcpcrypt
will depend on tcpeno, that is, but tcpeno doesn't depend on tcpcrypt).

     --dkg

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 30 Jul 2015 17:31:34 -0700

> exploit future TCP enhancements in a backward-compatible way.
Agreed. I highly support this new format.

> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 31 Jul 2015 11:24:41 +0200

> could use this mechanism (or something we evolve from it as a group)?

I think that separating out negotiation of the security protocol from the
protocol
itself is a really good idea (indeed, I suggested it a while ago and I
would have
no trouble splitting the TCP-use-TLS draft to use such a mechanism.

I haven't had time to give this draft a close read but it looks like it's
headed in the
right direction.

-Ekr

---

From: Brian Trammell <[email-masked]>
Date: Fri, 31 Jul 2015 15:20:50 +0200

Greetings, all,

> On 31 Jul 2015, at 11:24, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Fri, Jul 31, 2015 at 2:20 AM, Daniel Kahn Gillmor <[email-masked]> wrote:
> I think that separating out negotiation of the security protocol from the protocol
> itself is a really good idea (indeed, I suggested it a while ago and I would have
> I haven't had time to give this draft a close read but it looks like it's headed in the
> right direction.

I've read the draft.

I may have a few tiny nits to pick with the details of the extension mechanism, and it's not clear to me that section 4 should be in this (Standards Track) document, instead of a separate informational API document. But the approach is a sound way forward, separate from the question of what an eventual TCPINC protocol looks like, and I would support its adoption as a working group item, should such a call for adoption be issued.

Cheers,

Brian

---

From: Martin Thomson <[email-masked]>
Date: Fri, 31 Jul 2015 17:00:18 +0200

I have only had a quick skim of the draft.

Firstly, I think that this is the right sort of split to make if we hope to
make progress here.

However, in my view, the design (and the draft) could be made considerably
smaller and less complex.

A simpler design would mimic ALPN.  The initial SYN, would include a list
of options. The SYN+ACK would contain the selected option. A single octet
each should suffice for the option. tcpcrypt would need but a single
codepoint, as would tcp-use-tls.

The proposed design includes considerably more flexibility than needed. If
a specific choice of encryption requires more information to be carried in
option space, it can use another option.

It also occurs to me that this could be made generic; encryption is - at a
level of abstraction appropriate to this specification -  just a stream
filter on the connection. Maybe the same option could be used to enable
other such things (compression springs to mind, though that is likely be a
bad idea).
On Jul 31, 2015 12:26 AM, "David Mazieres" <

---

From: Ted Hardie <[email-masked]>
Date: Fri, 31 Jul 2015 10:24:51 -0700

I have read the draft, and I strongly support its adoption.  This is
exactly the sort of work that I believe that the working group can make
progress on even as there is ongoing discussion of the key agreement and
wire format.

There are a few places where I disagree with the draft's technical choices,
but that is, in my opinion, a good reason to adopt it:  it is already
concrete enough to start discussing the technical details.

Let's get it on board and get to work,

regards,

Ted