Re: [Tcpcrypt] v3 of the charter

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

El 30/04/14 10:20, Eggert, Lars escribió:
> Hi,
>
> a few comments. This is looking good overall.
>
> On 2014-4-30, at 8:35, marcelo bagnulo braun <[e-mail]> wrote:
>> 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
>> because it thwarts passive eavesdropping, but is weaker than using
>> authenticated keys, because it is vulnerable to man-in-the-middle attacks.
> 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?)

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

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


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

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

Regards, marcelo


> As I said, none of these are major.
>
> Lars