Re: [tcpm] Privacy problems of TCP Fast Open

[Michael Tuexen <[e-mail]>]

> On 21. May 2019, at 22:51, Erik Sy <[e-mail]> wrote:
> 
> 
> On 5/21/19 21:56, Michael Tuexen wrote:
>>> On 21. May 2019, at 21:22, Erik Sy <[e-mail]> wrote:
>>> 
>>> 
>>> On 5/21/19 18:34, Michael Tuexen wrote:
>>>>> On 21. May 2019, at 14:25, Erik Sy <[e-mail]> wrote:
>>>>> 
>>>>> 
>>>>> 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.
>>>> I also had this on my DSL line (I guess we both live in Germany),
>>>> but since my telephone line was moved to "all IP", the assignment stays
>>>> up for months.
>>>>> Additionally, I can initiate a change of my network's public IP address
>>>>> at anytime.
>>>> Sure.
>>>>> TFO cookies allow basically unlimited tracking periods because they do
>>>>> not have an expiration mechanism. Thus, even infrequently changed IP
>>>>> addresses can be correlated.
>>>> An implementation can do implement such a thing and even allow an API for it.
>>> Yes, I agree with you that implementations can go beyond RFC 7413 and
>>> implement an expiration mechanism limiting feasible tracking periods.
>>> 
>>>> For testing I'm flushing the cookie cache quite often...
>>>>>> 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.
>>>> They would share the IP address. If they decide to trigger a new address
>>>> binding on the access router, why couldn't they trigger flushing the
>>>> cache?
>>> Flushing the cache presents a performance versus privacy trade off
>>> because flushing increases the chance of a cache miss preventing a 0-RTT
>>> handshake.
>> Sure it does. It was just meant as an equivalent to resetting the
>> public IP address of your access router. This also affects all outgoing
>> connections.
>>> Thus, an application that often flushes the cache degrades the
>>> performance of all other applications sharing the same pool of TFO cookies.
>>> As a result, the application with the highest privacy requirements
>>> limits the TFO performance of all other applications.
>>> 
>>> Furthermore flushing has difficulties to separate applications running
>>> at the same time. For example, running a browser window in the normal
>>> browsing mode and another window in the private browsing mode
>>> (incognito). In this scenario, only excessive flushing can prevent an
>>> online tracker to link the user's online activities across both browser
>>> windows.
>> Can't they both be linked by the IP address being used?
> Tracking via IP addresses has the limitation that it cannot
> differentiate clients behind a NAT. However, TFO cookies can be used to
> overcome this limitation if each TFO connection from the same IP address
> gets assigned a unique token. Thus, reusing such a unique token during a
How does that work. Wouldn't the server compute the cookie based on the
IP address it sees from the client, which is the public address of the NAT,
and is the same for all clients? So I would assume that all clients behind
a NAT store and use the same TFO cookie.
> connection request allows a more accurate tracking than can be done via
> the publicly visible IP addresses.
>>> From my perspective, an approach that delegates the caching to the
>>> application itself, is the better solution to address this privacy
>>> versus performance trade off. Moreover, I believe users tend to make the
>> How does this prevent "tracking by IP-address" compared to "tracking
>> by TFO cookie"?
> As described, tracking by IP addresses has limitations especially if
> several users share the same IP address or change their publicly visible
> IP address frequently. As discussed, tracking via TFO cookies can be
> more persistent and more precise than tracking by IP addresses.
I don't see the more precise... See above. The more persistent I do see
and might be mitigated by timing out the TFO cookies.
> Applications controlling their retrieved TFO cookies can provide upper
> boundaries for feasible tracking periods via this mechanism without
> affecting the TFO performance of other applications. Furthermore,
> caching TFO cookies separately within each application prevents tracking
> user activities across these different applications on the same device.
But wouldn't the different applications on the same host use the same
IP address? Can't they the tracked by that in (almost the same way)?

Best regards
Michael
> 
> Best regards,
> Erik
> 
>> 
>> Best regards
>> Michael
>>> application/browser vendor responsible to protect their privacy. Thus,
>>> these vendors require appropriate measures to control their users' privacy.
>>> 
>>> Best regards,
>>> Erik
>>> 
>>>> Best regards
>>>> Michael
>>>>>>> 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
>>>>> 
>>>>>