Re: [Tcpcrypt] v3 of the charter

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

will do all these
thanks

El 30/04/14 10:41, Eggert, Lars escribió:
> On 2014-4-30, at 10:30, marcelo bagnulo braun <[e-mail]> wrote:
>> 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?
> 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.
>
>>>> - 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.
>> 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."
>
>> - 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.
>> 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