Re: [Tcpcrypt] v3 of the charter

[Joe Touch <[e-mail]>]

On 4/30/2014 2:38 PM, Daniel Kahn Gillmor wrote:
> 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.

Maybe. However, what you think of as a single host might be implemented 
as a set, e.g., for performance reasons.

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

I think of a fingerprint as providing more information than an address 
and port - something that persists even when multiple hosts share the 
same address and port.

> 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 don't know what everyone else is thinking of here.

IMO, fingerprinting is:

a) identifying a host
	e.g., in ways that let me differentiate different hosts used
	for load-balancing, even when they share the same addr and port

b) providing more info about a host
	e.g., when you can tell me that it's running Linux vs Windows,
	or which version, etc.

IMO, we should avoid both deliberate and accidental fingerprinting.

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

See above. I don't think fingerprinting has anything to do with 
addresses or ports.

Joe