Re: [Tcpcrypt] v3 of the charter

[Joe Touch <[e-mail]>]

On 4/30/2014 3:01 AM, David Mazieres wrote:
> marcelo bagnulo braun <[e-mail]> writes:
...
> 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."

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.

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

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

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

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

Joe