Subject: [Tcpcrypt] v3 of the charter

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 30 Apr 2014 08:35:12 +0200

Hi,

I have tried to incorporate the comments received. This resulted in 
quite a bit of changes, so, i would appreciate feedback (for example, 
feedback like "the charter looks great and is ready to go" would be 
nice, but if you have other feedback it will be welcome as well).

TCP Increased Security (TCP Inc.)

The TCP Inc. WG will develop the TCP extensions to provide unauthenticated
encryption and integrity protection of TCP streams. The WG will define an
unauthenticated key exchange mechanism. In addition, the WG will define the
TCP extensions to utilize unauthenticated keys, resulting in encryption and
integrity protection without authentication. This is better than plain-text
because it thwarts passive eavesdropping, but is weaker than using
authenticated keys, because it is vulnerable to man-in-the-middle attacks.
This work is part of the IETF effort to harness the Internet architecture
given the latest events of pervasive monitoring (see 
draft-farrell-perpass-attack).

The goal of this WG is to provide an additional security tool that 
complements
existing protocols at other layers in the stack. The WG will be looking 
for the
designs that find the right tradeoff spot between conflicting 
requirements: to
provide reasonable security for the majority of connections. Because we are
dealing with unprotected connections, we are more focussed on improving 
from
baseline of no security than achieving the high standard of security 
that is
already available to users of TLS. Providing unauthenticated
encryption and integrity protection at the TCP layer will provide a set of
features that cannot be achieved with existing tools, namely, encryption 
and
integrity protection without modifications to the upper ayers (no API 
changes),
encryption and integrity protection with forward secrecy with a 
per-connection
granularity, simple NAT and firewall traversal capabilities, key 
rollover without
significant impact to the TCP connection, lower overhead compared to 
solutions
relying in stacking multiple protocols to achieve different features, no 
manual
configuration required. A more detailed description of the motivations for
TCP-based solutions can be found in draft-bellovin-tcpsec-01 and in RFC5925.

The working group is looking to produce experimental documents 
specifying the
required TCP extensions and any additional documents needed.

The high-level requirements for the protocol for providing TCP 
unauthenticated
encryption and integrity protection are:

- Deployable and usable without significant changes to existing Internet
   infrastructure, in particular it must be compatible with NATs (at the
   very minimum with the NATs that comply with BEHAVE requirements as 
documented
   in RFC4787, RFC5382 and RFC5508);

- The protocol must be usable by unmodified applications.  This effort 
is complementary
   to other security protocols developed in the IETF (such as TLS) as it 
protects
   those applications and protocols that are difficult to change or may 
even not
   be changed in a backward compatible way.  It also provides some 
protection in
   scenarios where people are unwilling to do any change just for the 
sake of
   security (e.g., like configure encryption in an application).

- The protocol must provide cryptographic algorithm agility.

- Must gracefully fall-back to TCP if the remote peer does not support the
   proposed extensions

- When encryption is enabled, it must at least provide protection against
   passive eavesdropping by default,

- Should attempt to use the least amount of TCP option space, especially 
in SYN
   segments.

- Must not require any authentication or configuration from
   applications or users.  However, hooks for external authentication 
must be
   made available.  The WG will not work on new authentication mechanisms.

- The protocol must have acceptable performance.  For example, the 
protocol may
   try to re-use existing cryptographic material for future 
communication between the
   same endpoints to avoid expensive public key operations on connection 
set up.

When encryption is enabled, then the protocol:

- must always provide forward secrecy.

- must always provide integrity protection of the payload data (it is 
open for
   discussion for the WG if the TCP header should or not be protected)

- must always provide payload encryption.

- must not provide extra linkability. When encryption is enabled the TCP 
traffic should not
   give a third party observer any extra way to associate those packets 
with the
   specific peers beyond information that would have been present in a 
cleartext session.

- must allow client to avoid fingerprinting: some clients may want to 
avoid appearing as the same
   client when connecting to a remote peer on subsequent occasions.  
This should either
   be the default (clients cannot be "fingerprinted" by the server based 
on shared state)
   or some mechanism should be available for clients to drop or ignore 
shared state to avoid
   being fingerprintable any more than would be present for a cleartext 
session.

Security features at the TCP-level can benefit other TCP extensions.  For
example, both Multipath TCP and TCP Fast Open require proof that some 
connections are
related.  Session resumption and Message Authentication Codes (MACs) can 
provide
this evidence.  The working group should identify synergies and design the
security protocol in such a way that other TCP efforts can benefit from 
it.  Of
course, TCP extensions that break must be identified too, and kept to a 
minimum.

The working group will produce the following documents:

- A framework for unauthenticated encryption and integrity protection of 
TCP connections.
This document will describe basic design considerations, including the 
motivation and the
applicability of the proposed mechanism, the interaction with other 
security mechanisms in
different layers of the stack, the interaction with external 
authentication mechanisms, the
expected protection, privacy considerations and residual threats.

- Definition of the unauthenticated key exchange mechanism and the 
extensions to current TCP
to utilize unauthenticated key to provide encryption and integrity 
protection. This covers
all the protocol changes required. This will be an experimental document.

- An extended API describing how applications can obtain further 
benefits of the
proposed extensions. In particular, the hooks for supporting external 
authentication
will be defined in this document. This will be an informational document.

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 30 Apr 2014 08:20:10 +0000

Hi,

a few comments. This is looking good overall.

> TCP Increased Security (TCP Inc.)

am not in love with the name, but don't want to start a bikeshed.

> This is better than plain-text

Is it desirable to have a model where you're vulnerable to MiM the first time you connect to a server, but not afterwards? (Like what SSH provides in terms of warning when the server key has changed?)

>  very minimum with the NATs that comply with BEHAVE requirements as documented

What does "insignificant" mean here? I don't think we can require any changes to the current infrastructure.

> - The protocol must have acceptable performance.  For example, the protocol may
>  try to re-use existing cryptographic material for future communication between the
>  same endpoints to avoid expensive public key operations on connection set up.

There are two aspects to performance that this paragraph mixes together. One is latency, the other processing overhead. Reusing crypto material from previous instances may help with reducing latency overheads. But processing overhead matters, too. Servers wont be able to offload TCP Inc. (at least initially), and clients w/o crypto hardware acceleration of some sort will need to burn cycles (= battery). I don't want to compromise security (or latency) for reducing processing overheads, but we should be mindful of it.

> - must allow client to avoid fingerprinting: some clients may want to avoid appearing as the same
>  client when connecting to a remote peer on subsequent occasions.  This should either
>  be the default (clients cannot be "fingerprinted" by the server based on shared state)
>  or some mechanism should be available for clients to drop or ignore shared state to avoid
>  being fingerprintable any more than would be present for a cleartext session.

Not sure if this achievable if you can already fingerprint clients based on existing IP and TCP header fields.

As I said, none of these are major.

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 30 Apr 2014 08:27:54 +0000

Oh, forgot one more overall issue: The charter talks about clients and servers a lot. While that's convenient, because it matches the communication flow of the app layer protocols on top of TCP, and NATs now demand a directionality of connection establishment, those terms don't actually have a lot of meaning for TCP, which is a bidirectional protocol. Suggest to rephrase.

Lars

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 30 Apr 2014 10:30:41 +0200

> Is it desirable to have a model where you're vulnerable to MiM the first time you connect to a server, but not afterwards? (Like what SSH provides in terms of warning when the server key has change…

right, i will rephrase it as "vulnerable to mitm attacks during the 
initial unathenticated key exchange"

> What does "insignificant" mean here? I don't think we can require any changes to the current infrastructure.
well, there are lost of different boxes out there that do very wierd things.
I dont want people saying "there is a box that does foo and it is 
imcopatible with the proposed solution" and that being a blocking 
argument as per the charter, hence the significant, makes sense?

> There are two aspects to performance that this paragraph mixes together. One is latency, the other processing overhead. Reusing crypto material from previous instances may help with reducing latenc…

i agree, i am not sure if you want to relfect any of this in the charter 
and how

> Not sure if this achievable if you can already fingerprint clients based on existing IP and TCP header fields.

right, but see the last part of the last sentence (added by joe) This 
protocol must not do things worse, makes sense?

Regards, marcelo

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 30 Apr 2014 08:41:26 +0000

On 2014-4-30, at 10:30, marcelo bagnulo braun <[email-masked]> wrote:
> I dont want people saying "there is a box that does foo and it is imcopatible with the proposed solution" and that being a blocking argument as per the charter, hence the significant, makes sense?

Understood. Then maybe rephrase as something like "TCP Inc. should work over the vast majority of paths that unmodified TCP works over?" I.e., just talk about the expected outcome.

> i agree, i am not sure if you want to relfect any of this in the charter and how

I just picked up on it, because latency is specifically called out but processing overhead isn't. You could rephrase the first sentence as "The protocol extension must have acceptable latency and processing overheads."

> right, but see the last part of the last sentence (added by joe) This protocol must not do things worse, makes sense?

Makes sense. Suggest to express it this way, e.g., "the protocol extension must not increase the possibility for endpoint fingerprinting compared to what is possible already".

Lars

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 30 Apr 2014 10:02:04 +0100

Overall I think this charter (modulo wordsmithing such as
suggested by Lars) is good enough.

My own nit, but not suggesting a change...

On 30/04/14 09:41, Eggert, Lars wrote:
> Makes sense. Suggest to express it this way, e.g., "the protocol 
> extension must not increase the possibility for endpoint 
> fingerprinting compared to what is possible already".

I generally dislike when a security goal is set to be "no
worse than today" since I think that's how we got e.g. WEP.
But in this case (fingerprinting), I don't think we yet
understand it well enough to do much better. It'd be good
if we did though. So the text Lars suggests is ok.

S.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 30 Apr 2014 11:33:21 +0200

will do all these
thanks

---

From: David Mazieres <[email-masked]>
Date: Wed, 30 Apr 2014 12:01:36 +0200

> nice, but if you have other feedback it will be welcome as well).

At a high level, this is looking pretty good (modulo weird line breaks
that make it hard to read).

There are just a couple of places where I think the charter is
over-specifying things that might not be problems or that we might not
understand, and this could potentially cause problems down the line.

> protocol may try to re-use existing cryptographic material for future
> communication between the same endpoints to avoid expensive public key
> operations on connection set up.

Saying "The protocol must have acceptable performance" is superfluous.
By definition performance must be acceptable or we won't accept it,
unless you want to invite a debate on what is and is not acceptable
performance, which would then bifurcate into setup cost/latency and
per-byte/packet overhead.

How about, "In order to minimize connection latency, the protocol may
amortize the cost of public key operations over multiple connections
between the same pair of hosts."

> avoid appearing as the same client when connecting to a remote peer on
> subsequent occasions.  This should either be the default (clients
> cannot be "fingerprinted" by the server based on shared state) or some
> mechanism should be available for clients to drop or ignore shared
> state to avoid being fingerprintable any more than would be present
> for a cleartext session.

Both your text above, and the following suggestion by Lars:

> Makes sense. Suggest to express it this way, e.g., "the protocol extension
> must not increase the possibility for endpoint fingerprinting compared to what
> is possible already".

seem problematic to me.  The very fact that you are enabling a new TCP
extension is going to increase the ability to fingerprint (vs. hosts
that have not deployed TCP Inc. yet).

I think the right thing to do is for the informational RFC to suggest
APIs allowing hosts to be "virtualized" in some way, so that a single
physical host actively opening TCP connections through a NAT can appear
the same as an arbitrary number of hosts, subject to existing TCP
fingerprinting techniques and the fact that TCP Inc. is installed.  But
I'm wary of trying to specify that in the charter.

Would it be possible to drop the requirement in favor of something more
open-ended to the effect that consideration should be given to the
anonymity of hosts that change IP addresses or reside behind NATs?

David

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Apr 2014 08:23:39 -0700

On 4/30/2014 1:20 AM, Eggert, Lars wrote:
> Is it desirable to have a model where you're vulnerable to MiM the
> first time you connect to a server, but not afterwards? (Like what SSH
> provides in terms of warning when the server key has changed?)

It might be, but this might require configuration coordination between 
hosts that share ID info - whether at a load-server or behind a NAT.

...
> Not sure if this achievable if you can already fingerprint clients based on existing IP and TCP header fields.

It already says "any more than would be present for a cleartext 
session". Sure, you get the info that TCP-Inc is supported, but 
shouldn't need to expose more about the client than that.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Apr 2014 08:28:16 -0700

...
> between the same pair of hosts."

The protocol may do a lot of things; I don't think we should require 
this, necessarily - for the reason I already posted (configuration 
coordination complexity).

The text Marcelo proposed, IMO, left it open as to whether amortization 
was needed vs. the cost.

...
> I'm wary of trying to specify that in the charter.

Me too, esp. because that's a completely new capability that hasn't been 
demonstrated for non-secure TCP.

> anonymity of hosts that change IP addresses or reside behind NATs?

Again, IMO, that's getting too specific. I think the charter as-is is 
enough to proceed with a few possible approaches.

Joe

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 30 Apr 2014 16:06:57 -0400

> Oh, forgot one more overall issue: The charter talks about clients and servers a lot. While that's convenient, because it matches the communication flow of the app layer protocols on top of TCP, an…

TCP is bidirectional, but the handshake is asymmetric: one party
listen()s and accept()s, and the other party connect()s.  These parties
are widely known as the "server" and "client", respectively.    I think
that's what the draft charter refers to.  What other names do you
recommend using for these roles?

	--dkg

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Apr 2014 13:17:04 -0700

On 4/30/2014 1:06 PM, Daniel Kahn Gillmor wrote:
> listen()s and accept()s, and the other party connect()s.

TCP supports simultaneous open too. In which case, who's the client and 
who's the server?

Joe

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 30 Apr 2014 17:02:55 -0400

> Is it desirable to have a model where you're vulnerable to MiM the first time you connect to a server, but not afterwards? (Like what SSH provides in terms of warning when the server key has change…

I'd call this trust-on-first-use (TOFU) or leap-of-faith (LoF).  I'm not
sure it's appropriate for TCP Inc as currently designed, because these
models have serious problems with re-keying events.  In particular, what
do we expect a TCP Inc client to do if a host's key changes?  If it
aborts the connection, then we've violated the "don't display state to
the normual user" approach.  If it falls back to cleartext, then we're
back to plain TCP, unprotected even against passive attackers.

Keys get compromised; hosts fail and need to be rebuilt; there are
legitimate reasons to re-key.  If TOFU or LoF deals poorly with those
circumstances, and we include TOFU/LoF in TCP Inc, it would make
thoughtful sysadmins wary of rolling out TCP Inc, out of fear of what it
would do for their reachability.

this isn't to say that a layer above TCP Inc couldn't do TOFU or LoF,
based on the authentication hooks provided by TCP Inc, of course,
assuming that the authentication hooks are built in a way to support
that behavior.  But i don't think it belongs in TCP Inc itself as
currently framed.

	--dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 30 Apr 2014 17:06:14 -0400

> TCP supports simultaneous open too. In which case, who's the client and

In the simultaneous open case (does anyone actually use that in
practice?), both parties already know something about their peers (at
least, they know who they want to connect to).  From the perspective of
fingerprinting concerns, that suggests that they should both be treated
as servers, not as clients.

	--dkg

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Apr 2014 14:14:52 -0700

> as servers, not as clients.

They're also both clients because they issue the initial (non-ACK) SYN. 
So they're both - which is why most TCP protocol specification docs tend 
not to use the term client/server.

Joe

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 30 Apr 2014 17:19:54 -0400

> not to use the term client/server.

I know they're both clients in this sense; we're discussing
fingerprinting.  the charter text makes it clear that we want to be able
to avoid fingerprinting for the client, but not the server, since the
server presumably has some form of persistent identity, or else the
client wouldn't be able to connect to it in the first place.

That's the context in which i think we need to see TCP simultaneous open
as a server -- i don't think we need to worry about protecting
fingerprinting by the peer for either simultaneous open peer, since each
peer already has some information about the other.

	--dkg

(that said, i'm not sure how simultaneous open will work in whatever
spec we work out; maybe it turns out we have to be willing to sacrifice
simultaneous open in order to use tcp inc?)

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Apr 2014 14:27:48 -0700

On 4/30/2014 2:19 PM, Daniel Kahn Gillmor wrote:
...
> peer already has some information about the other.

It'd be optimal if this wasn't useful for fingerprinting either client 
or server. Even if you know the server's IP and port, that's all you 
ought to know, and all that needs to persist during the lifetime of a 
particular connection.

So why not just require anti-fingerprinting in general, and not focus on 
who initiated the connection?

> simultaneous open in order to use tcp inc?)

It should revert to conventional TCP and thus support simultaneous open 
in that case.

Joe

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 30 Apr 2014 17:29:07 -0400

> that have not deployed TCP Inc. yet).

decreasing the size of the client's anonymity set by a single bit
(derived from whether or not the client uses TCP Inc) is obviously
unavoidable.  But by the same token, if TCP Inc was widely deployed,
plain TCP sessions would also in an anonymity set of their own (just
with that bit set differently), so TCP Inc itself doesn't come out worse
than TCP.

But we want to avoid TCP Inc decreasing the client's anonymity set
further than that (e.g. we want a client using TCP Inc to be able to
appear as a different client (based on TCP Inc parameters) to a given
server on subsequent connections if it wants to).  For the charter, i
think Marcelo's text is reasonable.  Lars' suggestion of "what is
possible already" seems equivalent to "would be present for a cleartext
session" -- maybe what they both mean is best described as "no more
fingerprintable than a session without TCP Inc"

> I'm wary of trying to specify that in the charter.

I agree that this level of technical detail belongs in the RFC, but not
the charter.

> anonymity of hosts that change IP addresses or reside behind NATs?

This text sounds less open-ended to me than the text you're proposing to
replace.  In particular, i also care about machines that have a single
(non-changing) IP address and are not behind a NAT.  Those machines
should also be able to avoid fingerprinting from TCP Inc.  While it's
true they can be fingerprinted by their IP address, it's entirely
possible for multiple people to share a single IP address by time slices
(consider roommates with a cable modem who each plug their computers in
to the same plug at different times).

I think we should keep the language in the charter about enabling
clients to avoid any extra fingerprinting, since it identifies the goal
we want.

	--dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 30 Apr 2014 17:38:26 -0400

> who initiated the connection?

If i connect to the same server and port multiple times (or multiple
IP/port pairs, based on e.g. an SRV round-robin), i'm presumably doing
so because i know something about the service i'm trying to contact
already.  This persistence of identity is already in place, simply
because i'm making the same attempted connection; i'm not sure that
non-fingerprintability of services in this way is particularly meaningful.

It sounds like you might also be concerned about the case where a client
opens two connections to <IP Address A,Port P>, and <IP Address B,Port
Q>, which both happen to be operated by the same server; and we want the
server to be able to avoid leaking the information that it is the same
machine operating both services; is that right?

I'd be happy to see that case covered by TCP Inc.  If you think we can
simplify the charter by making it talk about non-fingerprintability of
peers in general and get it to cover this case, and avoid client/server
wording that people find objectionable, that'd be fine with me.

> It should revert to conventional TCP and thus support simultaneous open

I think we might be saying the same thing here -- if it turns out that
TCP Inc can't be done with simultaneous open, then you have to sacrifice
one feature or the other.

	--dkg

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Apr 2014 14:54:25 -0700

On 4/30/2014 2:38 PM, Daniel Kahn Gillmor wrote:
> already.

Maybe. However, what you think of as a single host might be implemented 
as a set, e.g., for performance reasons.

 > This persistence of identity is already in place, simply

I think of a fingerprint as providing more information than an address 
and port - something that persists even when multiple hosts share the 
same address and port.

> machine operating both services; is that right?

I don't know what everyone else is thinking of here.

IMO, fingerprinting is:

a) identifying a host
	e.g., in ways that let me differentiate different hosts used
	for load-balancing, even when they share the same addr and port

b) providing more info about a host
	e.g., when you can tell me that it's running Linux vs Windows,
	or which version, etc.

IMO, we should avoid both deliberate and accidental fingerprinting.

> wording that people find objectionable, that'd be fine with me.

See above. I don't think fingerprinting has anything to do with 
addresses or ports.

Joe

---

From: ianG <[email-masked]>
Date: Thu, 01 May 2014 00:07:59 +0100

...
> one feature or the other.

Yes, one or other.  My first instinct is to ask where and when is
simultaneous open used?  Opportunistic protection in TCP would be far
more important to me than something that isn't widely used, no matter
how elegant and exotic...

My second instinct would be to wonder if these discussions are arising
because the charter is still over-specified, too much detail in
isolation from some real contending protocols.  But that's possibly
because I think in terms of competition and unexpected benefits.

iang

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Apr 2014 16:31:13 -0700

On 4/30/2014 4:07 PM, ianG wrote:
...
> because I think in terms of competition and unexpected benefits.

FWIW, mine too - IMO, the issue of anti-fingerprinting can be specified 
without reference to role, in which case whether simultaneous open is 
supported or not can be determined in a candidate solution.

Joe

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 30 Apr 2014 17:10:13 -0700

On Wed, Apr 30, 2014 at 2:14 PM, Joe Touch <[email-masked]> wrote:

> They're also both clients because they issue the initial (non-ACK) SYN. So
> they're both - which is why most TCP protocol specification docs tend not
> to use the term client/server.
>

Are you attempting to describe TCP hole punching in a NAT firewall? If
that's the case, it's a race, and one side will win...

-- 
Tony Arcieri

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Apr 2014 17:14:44 -0700

On 4/30/2014 5:10 PM, Tony Arcieri wrote:
> On Wed, Apr 30, 2014 at 2:14 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     They're also both clients because they issue the initial (non-ACK)
>     SYN. So they're both - which is why most TCP protocol specification
>     docs tend not to use the term client/server.
>

Simultaneous open existed long before NATs.

Joe

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 30 Apr 2014 17:20:37 -0700

> Simultaneous open existed long before NATs.

It seems like another piece of minutia you are eagerly embracing long
before defining the rest of the protocol. How about addressing the 99.9%
case first?

-- 
Tony Arcieri

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Apr 2014 17:38:09 -0700

On 4/30/2014 5:20 PM, Tony Arcieri wrote:
> On Wed, Apr 30, 2014 at 5:14 PM, Joe Touch <[email-masked]

If by minutia, you mean "supports existing TCP capability", yes.

I don't see why any extension to TCP should do otherwise.

But yes, let's see what happens first - I don't see this as a 
non-starter if the corner cases are at least all addressed.

Joe