Re: [tcpm] Privacy problems of TCP Fast Open

[Erik Sy <[e-mail]>]

On 5/21/19 12:18, Michael Tuexen wrote:
>> On 21. May 2019, at 09:52, Erik Sy <[e-mail]> wrote:
>>
>> Hi Michael,
>>
>> thanks for this question!
>>
>> Yes, TFO cookies are bound to the clients (local) IP address. However, a
>> client with a static local IP address in a home network will use the
>> same TFO cookie independently of it's publicly visible IP address. As a
>> result, TFO cookies present an independent tracking mechanism, which
>> does not necessarily rely on the client's publicly visible IP address.
> How often do the public addresses change?

I do not have a general answer to your question. In the case of my home
network, my ISP assigns me at least every 24 hours a new IPv4 address.
Additionally, I can initiate a change of my network's public IP address
at anytime.

TFO cookies allow basically unlimited tracking periods because they do
not have an expiration mechanism. Thus, even infrequently changed IP
addresses can be correlated.

>  One could extend the TFO API in
> a way that the application can request a new cookie by only sending 
> a cookie request.

I do not think this is an appropriate countermeasure.

>From my perspective, caching TFO cookies in the kernel is a more
fundamental privacy problem. This design requires applications to share
a pool of TFO cookies, which allows tracking across several
applications. For example, this prevents user's to separate their online
activities across different browsers.

>> Returning to your example, onion routing does not necessarily protect
>> you against tracking via TFO cookies.
> Yepp, that is what I wanted to say. 
> But using TFO in that case doesn't
> make much sense.

Yes, TFO does not make sense if user privacy is at stake. Thus, we
should warn users about these risks of RFC 7413.

Best regards,
Erik