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 >>>>>>>>> >>>>>>>>>
- [tcpm] Privacy problems of TCP Fast Open Erik Sy
- Re: [tcpm] Privacy problems of TCP Fast Open Erik Sy
- Re: [tcpm] Privacy problems of TCP Fast Open Michael Tuexen
- Re: [tcpm] Privacy problems of TCP Fast Open Erik Sy
- Re: [tcpm] Privacy problems of TCP Fast Open Michael Welzl
- Re: [tcpm] Privacy problems of TCP Fast Open Michael Tuexen
- Re: [tcpm] Privacy problems of TCP Fast Open Erik Sy
- Re: [tcpm] Privacy problems of TCP Fast Open Brian Trammell (IETF)
- Re: [tcpm] Privacy problems of TCP Fast Open Michael Tuexen
- Re: [tcpm] Privacy problems of TCP Fast Open Michael Tuexen
- Re: [tcpm] Privacy problems of TCP Fast Open Praveen Balasubramanian
- Re: [tcpm] Privacy problems of TCP Fast Open Erik Sy
- Re: [tcpm] Privacy problems of TCP Fast Open Michael Tuexen
- Re: [tcpm] Privacy problems of TCP Fast Open Erik Sy
- Re: [tcpm] Privacy problems of TCP Fast Open Erik Sy
- Re: [tcpm] Privacy problems of TCP Fast Open Michael Welzl
- Re: [tcpm] Privacy problems of TCP Fast Open Olivier Bonaventure
- Re: [tcpm] Privacy problems of TCP Fast Open Erik Sy
- Re: [tcpm] Privacy problems of TCP Fast Open Praveen Balasubramanian
- Re: [tcpm] Privacy problems of TCP Fast Open Michael Tuexen
- Re: [tcpm] Privacy problems of TCP Fast Open Erik Sy
- Re: [tcpm] Privacy problems of TCP Fast Open Michael Tuexen
- Re: [tcpm] Privacy problems of TCP Fast Open Erik Sy
- Re: [tcpm] Privacy problems of TCP Fast Open Michael Tuexen