Subject: Re: [Tcpcrypt] v3 of the charter

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 01 May 2014 09:50:21 +0200

El 01/05/14 01:31, Joe Touch escribió:
>
>
> On 4/30/2014 4:07 PM, ianG wrote:
> ...
>> 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.
>
> 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.
>

could you propose text?

thanks, marcelo

> Joe
>
> _______________________________________________
> Tcpcrypt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpcrypt
>

---

From: David Mazieres <[email-masked]>
Date: Thu, 01 May 2014 08:04:27 -0700

>> simultaneous open is supported or not can be determined in a candidate 

How about eliminating the paragraph about anti-fingerprinting, and
instead changing this text:

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

To the following:

        ... In particular, the hooks for supporting external
        authentication will be defined in this document.  In addition,
        the document shall specify functions that allow control over any
        session parameters such as accepted ciphers or re-use of
        cryptographic material from prior sessions (if the protocol
        supports such re-use) and that help prevent multiple TCP
        Inc. connections from being linked to the same endpoint.

David

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 01 May 2014 22:03:29 +0200

>          Inc. connections from being linked to the same endpoint.

Thanks for the text

However, i am uncovinced we should link this to the API at this stage.
I mean, current charter text basically says avoid additional 
fingerprinting, doesnt link this to the API, i am dubious we should do this.
For instance, i would think legacy apps that dont support the extended 
API would also want to avoid fingerprinting.

What do you think?

Regards, marcelo

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 May 2014 13:17:30 -0700

>          Inc. connections from being linked to the same endpoint.

But that's not quite all of what fingerprinting implies.

I would suggest changing the current fingerprinting requirement:

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

to:

- must not increase information available for fingerprinting: endpoints 
should be identified by their IP address and port and no additional 
information should be provided that indicates the persistence of an 
endpoint or identity other than the IP address and port.

Joe

---

From: ianG <[email-masked]>
Date: Wed, 30 Apr 2014 12:19:06 +0100

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

I agree with all these points.  The goal is to get the designers to come
up with different attacks at the compromises possible.  It may be that
we accept a poorer performance if every other goal is met through a new
design;  conversely we may accept increased fingerprinting if the design
solves everything else...  I'd bet most will be happy to accept no
algorithm agility if there is a good version upgrade path ;)

We won't know until we see.

For this reason, I think most of the particular requirements should be
SHOULD, and should be rephrased in terms of "consideration be given
to..." or words to effect, as pointed out by David.  E.g.,

    "Consideration should be given to performance of latency, bandwidth
and CPU loading."

On the whole however, it's a lot better.  Thanks for removing the
requirement to turn it off!

iang

>> - 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.
> 
> 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."
> 
>> 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: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 02 May 2014 00:29:42 -0400

> endpoint or identity other than the IP address and port.

I know i raised the fingerprinting concern earlier here, but i'm
concerned that this statement actually goes too far.  "must not increase
information available for fingerprinting" implies that peers basically
cannot cache state between subsequent connections, which seems like an
obvious opportunity for performance improvements.

When a client connects to a server a second time, it's entirely
reasonable in many cases for the client to presume that the server is
the same server it spoke with last time and be able to prove it by doing
some sort of abbreviated handshake that presumes the server has some
known keying material.  Indeed, the "hooks for authentication" angle
seems to explicitly require the possibility of some sort of persistent
fingerprintability.

How about:

The repeated use of TCP Inc between two peers may provide information to
one peer that could be used to re-identify or "fingerprint" the other
peer in subsequent transactions.  Peers should be able to use TCP Inc
while avoiding leakage of any additional "fingerprinting" information
about themselves if configured or built to do so.

	--dkg

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 1 May 2014 21:35:12 -0700

> API would also want to avoid fingerprinting.

The TCP Crypt draft has a powerful feature: the APi can retrieve a session
identifier, which can then be used by applications to detect a MITM attack.
It would be a shame to preclude that in the charter.

-- Christian Huitema

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 02 May 2014 08:01:59 +0200

> It would be a shame to preclude that in the charter.

crypto material reuse and avoiding finger printing are contradictory 
requirements, i guess.
So, i guess it is up to the initiator to decide which one should it get, no?
This should be done through the API (which i guess is what David was 
referring to and i failed to understand)

I guess the difficulty is what should be the deafult behaviour i.e. when 
the upper layer donest support the extended API, but i dont think we 
need to nail this down in the charter....

---

From: Erik Nygren <[email-masked]>
Date: Fri, 2 May 2014 09:29:35 -0400

> referring to and i failed to understand)

The use-cases mentioned in the charter for multi-path TCP and TCP Fast Open
are also potentially contradictory, since the whole point of this for those
is authenticating a session as relating to another session (from other IP
addresses in the MPTCP use-case, even).

> endpoint or identity other than the IP address and port.

This opens up a server-side naming question:  does there need to be a way
to name service end-points beyond just IP address?  Given the limitations
of IPv4 address availability, TLS has found it necessary to introduce a
Server Name Indicator.  As long as tcpcrypt is doing just
anonymous/unauthenticated/etc encryption it may be that this isn't an issue
in some cases, but once we start introducing ways to configure keys
associated with service end-points, we start needing to have ways to name
those keys which starts to be hard without exposing additional
naming/routing/identity information.

---

From: David Mazieres <[email-masked]>
Date: Fri, 02 May 2014 08:34:43 -0700

> obvious opportunity for performance improvements.

Exactly.  I'm worried that we are over-specifying stuff before we
understand the design space or know the trade-offs.  In particular, it
turns out that TCP is pretty fingerprintable anyway (e.g.,
Kohno/Broido/Claffy) and adding a new option is only going to make that
worse.  (Hey, there's a reason my mail server, mail avenger, puts an
abstract of the SMTP connection's SYN segment in a mail header.)  So
really the charter is too early a place to decide to resolve these
trade-offs in favor of privacy.

To my mind, the only thing that's really in scope for the charter is to
say drafts should discuss their effects on fingerprinting.  If different
proposals facilitate fingerprinting to different extents, then this is
one thing to take into account when weighing one proposal against
another.

My personal opinion is that we want to optimize for speed in the common
case and ensure sufficient APIs are available that if people defeat all
the other fingerprinting techniques (from TCP to HTTP-level stuff) TCP
Inc. isn't the one thing left by which you can't avoid fingerprinting.
But remember, the API document is only going to be informational anyway.

So for all these reasons, putting language in the charter to the effect
that TCP Inc. must not exacerbate fingerprinting is likely to gunk up
the standardization process without necessarily yielding any improvement
in privacy.

By the way, this principal applies to most other aspects of the
protocol.  E.g., I see Erik Nygren brought up the issue of DoS
resilience.  That's a great point.  I suspect we will find that DoS
resilience is part of a complex four-way trade-off also involving
normal-case fingerprint-resistance, minimizing use of option space in
SYN segments, and minimizing connection latency.  Do we really want the
charter to prioritize fingerprint-resistance and option space over DoS
resilience and latency?  I'd rather line up a bunch of proposals and
then decide the trade-offs.

That means we should pick the minimum set of requirements.  If it were
up to me, I'd summarize the requirements in a mere three sentences:

    - In the absence of an active attacker, must provide forward secrecy
      between any two hosts that use it, with no configuration required.

    - For TCP-Inc.-aware applications, must provide endpoint
      authentication hooks that can guarantee forward secrecy and
      integrity of the TCP data stream against active attackers.

    - Must gracefully support incremental deployment over today's
      Internet.

Beyond that, I'd say there are a bunch of desirable properties, and
there are issues (like fingerprinting) that each draft must discuss.
But we shouldn't place any further *requirements* on the design.

David