Re: [Tcpcrypt] v3 of the charter

[Daniel Kahn Gillmor <[e-mail]>]

On 04/30/2014 05:27 PM, Joe Touch wrote:
> On 4/30/2014 2:19 PM, Daniel Kahn Gillmor wrote:
>> I know they're both clients in this sense; we're discussing
>> fingerprinting.  the charter text makes it clear that we want to be able
>> to avoid fingerprinting for the client, but not the server, since the
>> server presumably has some form of persistent identity, or else the
>> client wouldn't be able to connect to it in the first place.
>>
>> That's the context in which i think we need to see TCP simultaneous open
>> as a server -- i don't think we need to worry about protecting
>> fingerprinting by the peer for either simultaneous open peer, since each
>> peer already has some information about the other.
> 
> It'd be optimal if this wasn't useful for fingerprinting either client
> or server. Even if you know the server's IP and port, that's all you
> ought to know, and all that needs to persist during the lifetime of a
> particular connection.
> 
> So why not just require anti-fingerprinting in general, and not focus on
> who initiated the connection?


If i connect to the same server and port multiple times (or multiple
IP/port pairs, based on e.g. an SRV round-robin), i'm presumably doing
so because i know something about the service i'm trying to contact
already.  This persistence of identity is already in place, simply
because i'm making the same attempted connection; i'm not sure that
non-fingerprintability of services in this way is particularly meaningful.

It sounds like you might also be concerned about the case where a client
opens two connections to <IP Address A,Port P>, and <IP Address B,Port
Q>, which both happen to be operated by the same server; and we want the
server to be able to avoid leaking the information that it is the same
machine operating both services; is that right?

I'd be happy to see that case covered by TCP Inc.  If you think we can
simplify the charter by making it talk about non-fingerprintability of
peers in general and get it to cover this case, and avoid client/server
wording that people find objectionable, that'd be fine with me.


>> (that said, i'm not sure how simultaneous open will work in whatever
>> spec we work out; maybe it turns out we have to be willing to sacrifice
>> simultaneous open in order to use tcp inc?)
> 
> It should revert to conventional TCP and thus support simultaneous open
> in that case.

I think we might be saying the same thing here -- if it turns out that
TCP Inc can't be done with simultaneous open, then you have to sacrifice
one feature or the other.

	--dkg