Re: [tcpm] Privacy problems of TCP Fast Open

Michael Tuexen <> Thu, 23 May 2019 20:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B68F120123 for <>; Thu, 23 May 2019 13:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MmEOp2_-1MHs for <>; Thu, 23 May 2019 13:06:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1907D1200C5 for <>; Thu, 23 May 2019 13:06:15 -0700 (PDT)
Received: from [] ( []) (Authenticated sender: lurchi) by (Postfix) with ESMTPSA id A12337213B003; Thu, 23 May 2019 22:06:10 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Michael Tuexen <>
In-Reply-To: <>
Date: Thu, 23 May 2019 22:06:09 +0200
Cc: tcpm IETF list <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [tcpm] Privacy problems of TCP Fast Open
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 May 2019 20:06:19 -0000

> On 22. May 2019, at 23:42, Erik Sy <> wrote:
> On 5/22/19 22:25, Michael Tuexen wrote:
>>> On 22. May 2019, at 21:41, Erik Sy <> wrote:
>>> On 5/22/19 19:21, Michael Tuexen wrote:
>>>>> On 21. May 2019, at 22:51, Erik Sy <> wrote:
>>>>> On 5/21/19 21:56, Michael Tuexen wrote:
>>>>>>> On 21. May 2019, at 21:22, Erik Sy <> wrote:
>>>>>>> On 5/21/19 18:34, Michael Tuexen wrote:
>>>>>>>>> On 21. May 2019, at 14:25, Erik Sy <> wrote:
>>>>>>>>> On 5/21/19 12:18, Michael Tuexen wrote:
>>>>>>>>>>> On 21. May 2019, at 09:52, Erik Sy <> 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.
>>> TFO cookies are created and consumed by the server and are opaque to the
>>> client. Yes, there exist implementations that only use the client's IP
>>> address to generate the TFO cookie. However, it is up to the server to
>>> add additional information into the cookies as described in:
>>> Number 4. A server
>>> that wants to differentiate clients behind a NAT would make the cookies
>>> unique per connection.
>> Are you aware of such an implementation? 
> I did not investigate the default mechanisms different operating systems
> use to generate TFO cookies. However, patching a kernel to generate
> unique TFO cookies for connections from the same IP address is certainly
> feasible for online trackers. For example, one can use an truncated hash
> of the client's IP address appended by a counter to construct such a
> unique cookies.
Sure. But this can always be done by the issuer of the cookie. Or am I missing
>> Doesn't that mean that a server
>> has the capability to differentiate clients behind a NAT to provide different
>> TFO cookies? If he has the capability, why does he need TFO cookies?
> No. Let's assume we have two clients behind a NAT with the same public
> IP address. The first client receives a unique TFO cookie during its
> first connection. When this client reconnects to the server, it will
> present the cookie received during it's first connection. This allows
> the server to conclude that both connection originate from the same host
> because this cookie was only issued a single time. The second client
> will receive a different TFO cookie during it's first connection. Thus,
> both clients can be clearly differentiated by the server.
As said above: If the issuer of the cookie wants to do that, it is possible.
This is a consequence of of using a cookie mechanism.

As far as I know, neither Linux nor FreeBSD build the cookie in a way to
send you different ones for different clients behind a NAT.

Best regards
>>>>> 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)?
>>> Most applications on the same host will certainly use the same IP
>>> address. However, this does not have to be the case. For example, every
>>> popular browser allows you to configure an application specific proxy
>>> that can change the publicly visible IP address of it's traffic (similar
>>> to the TorBrowser).
>> OK. So the server sees multiple proxies talking to him. Since the proxies
>> terminate the TCP connections, the server would not see the TFO cookies,
>> which were provided by the proxies to the clients.
> There exist different types of proxies. I thought of gateways/
> tunnelling proxies that only change the publicly visible IP address
> similar to onion routing. Thus, the client's TFO cookie will be
> forwarded to the server.
> Best regards,
> Erik
>> Best regards
>> Michael
>>> Best regards
>>> Erik
>>>> 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