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

From: John-Mark Gurney <[email-masked]>
Date: Sun, 2 Aug 2015 10:37:33 -0700

David Mazieres wrote this message on Thu, Jul 30, 2015 at 15:26 -0700:
> My vote is to adopt both TCP-ENO and tcpcrypt, which together provide an
> obvious path for harmonization.

Is the goal of this draft to get down to one spec? or to allow both
specs to become standards?

>From what I see, this allows both specs to become standard, which is
a bad idea...  The WG charter specifically says: "to provide reasonable
security for the majority of connections.", but if we adopt this, it
will allow vendors to pick only one of two (or more), claim that they
support always on encryption, and then a majority of connections will
not be encrypted because there will be a protocol mismatch.

Expecting OS vendors to implement all protocols again is not a good
idea... They will want to put their eggs in one basket, and watch that
basket closely, pay for security audit, etc.

So, as far as I can see, this draft runs counter to the WG charter and
should not be considered...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

---

From: John-Mark Gurney <[email-masked]>
Date: Sun, 2 Aug 2015 13:16:38 -0700

David Mazieres expires 2015-10-31 PDT wrote this message on Sun, Aug 02, 2015 at 12:08 -0700:
> John-Mark Gurney <[email-masked]> writes:
> 
> Well, the working group charter is to produce three documents
> (framework, protocol, and API).  Hence, unless we re-charter, we would
> have to reorganize the documents.  Part of TCP-ENO (like the normative
> requirements for a Session ID) might move into the framework document,
> which would then have to be classified as experimental rather than
> informational.  (The charter doesn't specify the status of the framework
> document.)  Then other parts of TCP-ENO would be merged with tcpcrypt or
> TCP-use-TLS to produce a protocol document.

Then why does the draft allocate both id's to both, if it comes down
to one or the other?  Shouldn't we just allocate a range for the
implementation that the WG decides upon?

> I think this is absolutely a valid concern.  The working group should
> not standardize two transport-layer protocols and use TCP-ENO to switch
> between them.  At the same time, I think we should be highly mindful of
> future developments and needs.  So that means that while we could have
> written TCP-ENO as just a simple cipher-suite negotiation mechanism, we
> also wanted to account for the possibility that TCPINC may need to
> evolve in much more radical ways than just cipher suites.
> 
> A good example is what happens if someday we get large options in SYN
> segments?  Well, this would potentially allow us to shave round-trip
> times from TCPINC, which is not the kind of performance win we'd want to
> leave on the table.  But the resulting changes would be different enough
> from anything we have that we'd want to negotiate it straightaway in the
> SYN using variable-length suboptions.
> 
> Another issue is that TCPINC should be the transport-layer encryption
> mechanism for the Internet.  But TCP-ENO can potentially be used to
> negotiate application-layer encryption as well.  There's a plausible
> scenario in which TLS can hugely benefit from just one out-of-band bit
> to negotiate library-level use of TLS in a backwards compatible way.
> 
> Looking back to Andrea's tcpcrypt slides from IETF89:
> 
>         http://www.ietf.org/proceedings/89/slides/slides-89-tcpm-9.pdf
> 
> The goal he laid out was to attack the problem of unencrypted traffic on
> two fronts--increase TLS adoption at the application layer as much as
> possible, and then enable transport-level encryption for the remaining

Correct, as TLS provides authentication...

> cases.  So while increasing TLS is not strictly within the TCPINC
> charter, if there's room in TCPINC to reserve "one bit" for the TLS
> working group, it might be prudent to do so.
> 
> Again, I think this is absolutely a valid concern.  To illustrate this
> with some completely made up numbers, we could find ourselves in a
> situation where giving one bit to the TLS working group allows people to
> go from 50% to 70% adoption of TLS overnight, and that's enough of an
> improvement that people lose interest in TCPINC.  But if TCPINC had been
> the only backwards compatible solution, then everyone would have
> implemented it in their kernels and gotten us to 90% encryption.  But
> also if everyone implemented TCPINC and we gave TLS the extra bit, then
> maybe we could get to 95% encryption.
> 
> This is a question I'm a little ambivalent about because it requires
> predicting the future.  But with something like TCP-ENO, we have the
> groundwork to go in whichever direction the working group decides, and
> also more leeway to change our minds down the road.

I do agree that giving the "bit" could increase TLS deployment, but
from past experience, everyone will do the minimal amount to work to
be compliant, so if there's an option of just using the bit, and saying,
oh, we support and have implemented the TCPINC standard, but require
applications to be modified, then then WG has failed...

The scary part is that this is apparently the goal of the TLS-use-TCP
spec, as it explicitly allows a conforming implementation to only do
userland hand off:
   There are two primary implementation options for TCP-TLS:

[...]

   o  Implement just the TCP-TLS negotiation option in the operating
      system kernel with an interface to tell the application that TCP-
      TLS has been negotiated and therefore that the application must
      negotiate TLS.

So, if TCP-ENO is adopted, and ths TLS-use-TCP draft is adopted, they
just have to do TCP-ENO, and no other work, and they've fully
implemented the TCPINC WG recommendations, but we have made very little
headway to encrypting the internet traffic.

---

From: David Mazieres <[email-masked]>
Date: Sun, 02 Aug 2015 13:18:47 -0700

David

---

From: David Mazieres <[email-masked]>
Date: Sun, 02 Aug 2015 13:24:35 -0700

Martin Thomson <[email-masked]> writes:

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

TCP-ENO can be used this way.  Indeed, if you don't use the
configuration byte or variable-length suboptions, then you get one octet
per offered option in the SYN, and one byte for the accepted option in
the SYN+ACK.  However, there is a good design rationale for the
configuration byte and variable-length suboptions.

Having the configuration byte standardized across protocols ensures that
the most important OS-level API changes (extra getsockopt/setsockopt
calls) can be amortized over multiple versions of TCPINC.  In
particular, the Application Aware bits are as fundamental as the session
ID, so really need to be handled at the negotiation level.

If people want to get rid of the "p" bit, we'd certainly be open to
suggestions on how to handle simultaneous open.  There are other ways to
do it, but having one bit and requiring applications to set it properly
was just the simplest thing we could think of.  Well, okay, simpler
would be to sort the spec identifiers and pick the lowest- or
highest-numbered spec identifier common to both SYNs.  However, we think
people need to be able to configure spec priority.  Plus, most
encryption specs are likely to need symmetry breaking anyway, so we
might as well solve the problem once.

Variable-length options are critical to low latency.  Tcpcrypt needs to
include a few bytes in the SYN and SYN+ACK packets for public key cipher
negotiation and for session caching.  Removing this feature would incur
an extra round trip before data can be exchanged in tcpcrypt or any
future protocol.  That would be particularly unfortunate if we ever get
large option support in SYN segments or make a tailored TCPINC for fast
open.

Because variable-length options are optional, you don't have to use them
if you don't need them.  We allocated two fixed and two variable length
suboptions each to tcpinc and TLS to err on the side of generosity, so
people working on each spec have maximum flexibility until we see how
this plays out in practice.  I'd be surprised if any spec actually used
all four of its suboptions.

David
 Ted Hardie <[email-masked]> (Fri. 10:24) ()
Subject: Re: [tcpinc] TCP-ENO: Encryption Negotiation Option
To: David Mazieres expires 2015-10-28 PDT <[email-masked]>
Cc: tcpinc <[email-masked]>
Date: Fri, 31 Jul 2015 10:24:51 -0700

[ multipart/alternative ]
[ text/plain ]
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

On Thu, Jul 30, 2015 at 3:26 PM, David Mazieres <
[email-masked]> wrote:

> The tcpcrypt team is as committed as ever to contributing to continued
> improvement, standardization, and deployment of tcpcrypt should the
[ 49 more citation lines. Click/Enter to show. ]
> 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.
>
> _______________________________________________
> Tcpinc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpinc
[ text/html (hidden) ]
 John-Mark Gurney <[email-masked]> (Today 10:37) (replied)
Subject: Re: [tcpinc] TCP-ENO: Encryption Negotiation Option
To: David Mazieres expires 2015-10-28 PDT <[email-masked]>
Cc: [email-masked]
Date: Sun, 02 Aug 2015 10:37:33 -0700

[ 4-line signature. Click/Enter to show. ]
-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
  David Mazieres expires 2015-10-31 PDT <[email-masked]> (Today 12:08) (inbox replied)
Subject: Re: [tcpinc] TCP-ENO: Encryption Negotiation Option
To: John-Mark Gurney <[email-masked]>
Cc: [email-masked]
Date: Sun, 02 Aug 2015 12:08:22 -0700

David

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Aug 2015 13:29:03 -0700

> headway to encrypting the internet traffic.

You've made this point several times and I have to say I don't really
understand
it. Vendors need not ship TCPINC now and won't have to regardless of what
we standardize. So, yes, they could do as you suggest, but if their
intention
is not to provide automatic encryption to their users, it would be far
easier
to simply not implement TCPINC at all, rather than just implement an
in-kernel flag.

With that said, I think that the mode you mention above *is* of value to
users
because it allows out of band negotiation of TLS, so I would hope that
vendors would
implement both a version that upgraded all applications and one that just
allowed applications to upgrade themselves [0].

-Ekr

[0] It's worth noting that yet another way to implement TCP-use-TLS is with
the split indicated here but with the TLS implementation in userspace via
libc modifications shims. This seems like a valid implementation technique
and I'm
not sure what the objection would be to a vendor doing this.

---

From: David Mazieres <[email-masked]>
Date: Sun, 02 Aug 2015 14:04:28 -0700

> implementation that the WG decides upon?

Two reasons.  First, a draft is just a draft.  We don't expect it to
stay that way.  But to the extent that people like TCP-ENO yet still
aren't sure about tcpcrypt vs. TCP-use-TLS, it seemed kind of impolite
not to allocate separate numbers to both protocols so that people could
tinker with implementations of both in parallel.

Second, note that we actually allocated the 4 numbers to the TLS working
group, not to TCP-use-TLS.  They could potentially make use of that for
application-level instead of transport-level encryption.  But again,
it's just a draft, and for a draft it seems better to err on the side of
inclusiveness (and have the working group whittle things down) than vice
versa.

> Correct, as TLS provides authentication...

Well, TLS can provide authentication, but it can't do it with only
information expressed through existing transport-level APIs (i.e.,
basically just a sockaddr_in[6]).  So I think TCP-use-TLS are pretty
much in the same boat when it comes to authentication, except that
tcpcrypt has application-aware bits that allow authentication to be done
in a backwards compatible way.

One of the advantages of TCP-ENO's approach is that it standardizes the
notion of application-aware bits, thereby facilitating the transition
from opportunistic encryption to authenticated endpoints.

> headway to encrypting the internet traffic.

Yup, that's a totally valid concern.  My only quibble is that
library-level code wouldn't be implementing TCPINC (which would be
either tcpcrypt or TCP-use-TLS), but would have implemented TCP-ENO.
Once you buy into a library-level implementation, there is no reason to
stick to the transport-level API--e.g., the library should have access
to DNS names, etc., so it wouldn't be TCPINC.

That said, the risk you outline is not a certainty.  While ending up
with a valid TCP option for tcpcrypt doesn't guarantee deployment,
staying deadlocked and/or waiting for TLS1.3 to catch up does guarantee
no deployment of transport-layer encryption any time soon.  There are
worse outcomes than triggering a friendly competition between the TLS
and TCPINC working groups to see whether we can deploy opportunistic
encryption faster at the transport layer or the application layer: at
the point the two efforts collide, 99% of TCP traffic will be encrypted.

Remember it's not just that the room was pretty split in Prague, it's
that a noticeable majority of people in the room hummed they would not
change their minds.  We are deadlocked on the question of tcpcrypt vs.
TCP-use-TLS.  TCP-ENO is an attempt to change the question to one we
might not be deadlocked on, and to provide advantages to TLS even if
TCP-use-TLS is not selected.  Allocating a few suboptions to the TLS
working group means that standardizing TCP-ENO + tcpcrypt would benefit
TLS more than TCPINC standardizing nothing at all.

David

---

From: John-Mark Gurney <[email-masked]>
Date: Sun, 2 Aug 2015 23:14:18 -0700

> it. Vendors need not ship TCPINC now and won't have to regardless of what

Then why even have this option?  If you don't think vendors will
implement this option?

> to simply not implement TCPINC at all, rather than just implement an

You forget that vendors play the standards game...  You must adhere
to standard X, or your product must follow an open standard...  But
at various levels, they just say, oh, supports automatic encryption,
must be good, but fail to understand that it required application
modification, or that though they support RFCxyz that does automatic
encryption, it isn't...

If two vendors have conforming implementations of the output of this
WG, and they do not encryption all the TCP connections between them,
then I consider that a failure on this WG to do it's charter...  With
that option, this can happen...

> allowed applications to upgrade themselves [0].

I'm not saying that it shouldn't be an option, but it isn't this WG's
charter to do this...  If you feel that strongly about this option,
then bring it up as part of the TLS WG or another one...  But this WG
is about enabling always on encryption...

> not sure what the objection would be to a vendor doing this.

If they ship w/ it in libc, and fully on by default, and applications
run w/o modifications, then and conforms to the specification, then
that's a valid implementation..

I don't understand your resistance to having all conforming
implementations of the specification support automatic encryption?

---

From: John-Mark Gurney <[email-masked]>
Date: Sun, 2 Aug 2015 23:23:49 -0700

> inclusiveness (and have the working group whittle things down) than vice

Ahh, I confused the TLS working group as TLS-use-TCP and not a
seperate group, I appologize for misreading...  I guess calling it
tcpcrypt instead of tcpinc didn't help me either... I'd recommend
renaming tcpcrypt to tcpinc to denote that it's the place holder
for the output of this WG, not tcpcrypt specific...

> to DNS names, etc., so it wouldn't be TCPINC.

You're missing the point if the TCPINC standard allows for a
conforming implementation to only support userland hand-off w/o
requiring default support in libc or other layer so that automatic
encryption always happens w/ a supported peer, then they HAVE
implemented TCPINC to the letter, but not the spirit...

THAT is my concern, that vendors will implement the letter, but not
the spirit of the standard...

> That said, the risk you outline is not a certainty.  While ending up

No, it's not, but neither is that what this WG outputs will achieve
it's goals, I'd just like to have it air tight that a conforming
implementation achieves this WG's goals...

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Aug 2015 04:07:33 -0700

> Then why even have this option?  If you don't think vendors will

I didn't say that vendors wouldn't implement this option. As I said, I think
it would be good if vendors implemented *both* an automatic option
that required no application intervention *and* an option which allowed
the application to do out-of-band negotiation.

What I don't think vendors will do.

> modification, or that though they support RFCxyz that does automatic

OK, I now see what you're saying. I've never found this argument to be
particularly persuasive as an argument for 2119-level MUST requirements.
That may be true in some cases where, for instance, the customer generally
wants some functionality (e.g., SIP) and then they have a list of the
RFCs that constitute conformance, but I don't generally think it's going
to be that useful a strategy for vendors to nominally implement some RFC and
then have it not encrypt anything.

> then I consider that a failure on this WG to do it's charter...

Well, I definitely don't agree with this. For instance, I don't want
implementations to be required to encrypt traffic that is already TLS
encrypted. So, regardless of implementation technique, it's not going
to the case that implementations of this specification offer encryption
on every single TCP connection. My sense is that that reflects the
general feeling of the WG as well.

> is about enabling always on encryption...

Yeah, I think this is unduly focusing on the implementation. This WG is
about
defining *protocol* and the protocol the implementation technique that I
describe produces identical wire format behavior, and I think there is a
useful space for an implementation such as I describe, for a number
of reasons, not just implementation convenience. Specifically:

- It's much safer for vendors to ship and users to turn on because it
  puts the responsibility for potential breakage on the application, which
  is better able to bear it (this is a real problem with any new protocol
  rollout at this point, which is why people implement fallback).

- It allows applications to gradually shim their way up to non-opportunistic
  security as Christian indicates.

However, if you're worried about people gaming the system, then I sugges
that something like the proposed ENO draft provides a good mechanism for
meeting
both our requirements. Simply have two RFCs, one of which defines
the protocol and one of which defines the "on-by-default" behavior you're
concerned with. This allows us to define flexible mechanisms while
allowing for a seal of approval that defines a specific behavior.

> that's a valid implementation..

Great.

-Ekr

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 3 Aug 2015 14:05:53 +0200

Hi all,

quick comment on this:

> Am 02.08.2015 um 22:18 schrieb David Mazieres <[email-masked]>:
> 
> have to reorganize the documents. 

The wg is chartered to produce these three documents. However, the working group may choose to produce more documents if they are in scope of the charter. 

I personally would like to (currently) not work on more documents than needed, as one of the goals of the working is to produce some results as soon as possible (as otherwise our work might not be needed anymore). However, if more document actually help to speed up things because separate issues can be discussed separately, we definitely can have more than these three docs. Further even if we adopt multiple docs as wg doc, there is always a possibility to (re-)merge later.

Moreover, if we figure out over time while working on the solution that the three documents as outlined in the charter are not the rights ones, we can easily recharter. I’m pretty sure we want a protocol spec and it’s good practice to have a separate and informational API doc, but the framework doc might need further discussion…

Mirja

---

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 3 Aug 2015 14:07:43 +0200

Hi all,

> evolve in much more radical ways than just cipher suites.

+1. I think there need to be a way to ‚update‘ most part of the approach. However, there should probably one basic approach where all implementation have to be backward compatible to.

---

From: John-Mark Gurney <[email-masked]>
Date: Mon, 3 Aug 2015 12:38:24 -0700

> I didn't say that vendors wouldn't implement this option. As I said, I think

You did say: "but if their intention is not to provide automatic
encryption to their users, it would be far easier to simply not
implement TCPINC at all, rather than just implement an in-kernel flag."

So, that's how I read that either a vendor will implement the full
version of TCPINC, or not at all...

> the application to do out-of-band negotiation.

I agree that it would be good if they did both...

> Well, I definitely don't agree with this. For instance, I don't want

You don't agree that if two implementations should always result in an
encryption connection of some kind?  I specificly left out how the TCP
connection was encrypted, be it userland TLS because both sides signaled
it could do that, or the always on, anonymous encryption put forth by
this WG...

> encrypted. So, regardless of implementation technique, it's not going

If it's encrypted by TLS, then I consider that a encrypted TCP
connection..

> general feeling of the WG as well.

If a connection signals that it does not want encryption (are we even
going to provide this option), then that is exempt from my argument,
but the whole point of this WG is to encrypt all TCP connections... Do
I need to quote the charter again?

> defining *protocol* and the protocol the implementation technique that I

I can't parse: "and the protocol the implementation technique"

> of reasons, not just implementation convenience. Specifically:

I agree that there is useful space for your described behavior, I just
don't think that this WG is the correct place for protocol that will
not ensure as many connections as possible are encrypted...

> allowing for a seal of approval that defines a specific behavior.

I disagree w/ this.  There should be the protocl that requires
"on-by-default" behavior, and the TCP-ENO draft that allows the
negotiation of your idea, userland shim or the "on-by-default"
behavior...

It could be that I'm misunderstanding what you call the protocol...
I'm calling the protocol, either the TLS-use-TCP or tcpcrypt the
protocol, and then ENO is just a signalling mechnism which is different..

> > that's a valid implementation..

I forgot to include that the connections are always encrypted unless
otherwise controled (via application or system admin)...

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 3 Aug 2015 13:24:12 -0700

On Mon, Aug 3, 2015 at 12:38 PM, John-Mark Gurney <[email-masked]> wrote:

> Eric Rescorla wrote this message on Mon, Aug 03, 2015 at 04:07 -0700
>

> it could do that, or the always on, anonymous encryption put forth by

I think it's completely legitimate and should be conformant for
implementations
to be configurable so they only offer tcpinc on some TCP connections. They
might do that to allow for space for application-level encryption or for
other
reasons. I don't see anything in the charter that prohibits this.

> I can't parse: "and the protocol the implementation technique"

s/and the protocol//

> protocol, and then ENO is just a signalling mechnism which is different..

Well, I'm more than happy to have some RFC that says "you must have this on
by default for every connection unless someone turns it off by some
mechanism
and then people can be conformant to that RFC or not. I'm not happy to have
the mechanism that this WG defines for signaling require that policy, since
I think it's unduly restrictive. And since the wire protocol is the same
regardless,
I don't really see the issue.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Tue, 4 Aug 2015 10:33:40 -0700

> codepoint, as would tcp-use-tls.

If you have a TCP option codepoint for ENO you shouldn't need any
others. The rest of the parameters - including which mechanism is used -
should be part of the negotiation inside the option.

Joe