Re: [Tcpcrypt] v3 of the charter

[Joe Touch <[e-mail]>]

On 4/30/2014 2:19 PM, Daniel Kahn Gillmor wrote:
...
>> They're also both clients because they issue the initial (non-ACK) SYN.
>> So they're both - which is why most TCP protocol specification docs tend
>> not to use the term client/server.
>
> 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?

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

Joe