Re: [tcpm] Privacy problems of TCP Fast Open

Michael Tuexen <michael.tuexen@lurchi.franken.de> Thu, 23 May 2019 20:06 UTC

Return-Path: <michael.tuexen@lurchi.franken.de>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B68F120123 for <tcpm@ietfa.amsl.com>; Thu, 23 May 2019 13:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmEOp2_-1MHs for <tcpm@ietfa.amsl.com>; Thu, 23 May 2019 13:06:15 -0700 (PDT)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1907D1200C5 for <tcpm@ietf.org>; Thu, 23 May 2019 13:06:15 -0700 (PDT)
Received: from [192.168.1.2] (p57BB45F7.dip0.t-ipconnect.de [87.187.69.247]) (Authenticated sender: lurchi) by mail-n.franken.de (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 <michael.tuexen@lurchi.franken.de>
In-Reply-To: <0a474aad-623f-8974-c52e-e832dc1f780d@informatik.uni-hamburg.de>
Date: Thu, 23 May 2019 22:06:09 +0200
Cc: tcpm IETF list <tcpm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2DDFC67A-C0E4-468D-85BF-645BCAAC1C52@lurchi.franken.de>
References: <ba3887b6-1554-9a67-8834-4bb598cf18f0@informatik.uni-hamburg.de> <fd9f22b0-03ee-a1ef-ee97-02a93bf2648b@informatik.uni-hamburg.de> <4194EE28-DCDF-46A3-8D26-5920E55040FD@lurchi.franken.de> <4e151b52-cd6d-7145-4e0f-94c6f94eb20b@informatik.uni-hamburg.de> <DA807D25-9E7F-4EE3-8E8B-C9A0FC745C52@lurchi.franken.de> <5804f1d1-5f47-6f36-be9f-d13d9ad89b08@informatik.uni-hamburg.de> <090B342F-960D-4F0D-ABF4-5E29E6BAF2AA@lurchi.franken.de> <a6411190-fc9c-3f4d-470d-796023f68a1e@informatik.uni-hamburg.de> <493C742D-0671-40EC-80B7-0C06171595C1@lurchi.franken.de> <40c42c9b-da69-f996-e336-8b32b159accc@informatik.uni-hamburg.de> <72266B1A-6103-4602-8087-009A37EC80C5@lurchi.franken.de> <2f3a0382-e156-a25f-df34-58946ef488bc@informatik.uni-hamburg.de> <7A3BBF13-C650-4AE2-B69A-18A1F5151DC7@lurchi.franken.de> <0a474aad-623f-8974-c52e-e832dc1f780d@informatik.uni-hamburg.de>
To: sy@informatik.uni-hamburg.de
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/_LgeFg7MxcHybNKfTwNES1ny3PU>
Subject: Re: [tcpm] Privacy problems of TCP Fast Open
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 May 2019 20:06:19 -0000


> On 22. May 2019, at 23:42, Erik Sy <sy@informatik.uni-hamburg.de> wrote:
> 
> 
> On 5/22/19 22:25, Michael Tuexen wrote:
>>> On 22. May 2019, at 21:41, Erik Sy <sy@informatik.uni-hamburg.de> wrote:
>>> 
>>> 
>>> On 5/22/19 19:21, Michael Tuexen wrote:
>>>>> On 21. May 2019, at 22:51, Erik Sy <sy@informatik.uni-hamburg.de> wrote:
>>>>> 
>>>>> 
>>>>> On 5/21/19 21:56, Michael Tuexen wrote:
>>>>>>> On 21. May 2019, at 21:22, Erik Sy <sy@informatik.uni-hamburg.de> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> On 5/21/19 18:34, Michael Tuexen wrote:
>>>>>>>>> On 21. May 2019, at 14:25, Erik Sy <sy@informatik.uni-hamburg.de> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 5/21/19 12:18, Michael Tuexen wrote:
>>>>>>>>>>> On 21. May 2019, at 09:52, Erik Sy <sy@informatik.uni-hamburg.de> 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:
>>> https://tools.ietf.org/html/rfc7413#section-4.1.2 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
something?
>> 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
Michael
> 
> 
>>>>> 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
>>>>>>>>> 
>>>>>>>>>