Re: [Tcpcrypt] v3 of the charter

["Eggert, Lars" <[e-mail]>]

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

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

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

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

As I said, none of these are major.

Lars