Re: [Tcpcrypt] v3 of the charter

[David Mazieres <[e-mail]>]

marcelo bagnulo braun <[e-mail]> writes:

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

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.

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

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

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