Re: [tcpm] Privacy problems of TCP Fast Open

Erik Sy <sy@informatik.uni-hamburg.de> Tue, 21 May 2019 19:22 UTC

Return-Path: <sy@informatik.uni-hamburg.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 7D3DF120025 for <tcpm@ietfa.amsl.com>; Tue, 21 May 2019 12:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 qTTgNwqTLLj5 for <tcpm@ietfa.amsl.com>; Tue, 21 May 2019 12:22:33 -0700 (PDT)
Received: from mailhost.informatik.uni-hamburg.de (mailhost.informatik.uni-hamburg.de [134.100.9.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7566A120096 for <tcpm@ietf.org>; Tue, 21 May 2019 12:22:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id E4B42FD5; Tue, 21 May 2019 21:22:24 +0200 (CEST)
X-Virus-Scanned: amavisd-new at informatik.uni-hamburg.de
Received: from mailhost.informatik.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.informatik.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id L8q+Nk7dYxob; Tue, 21 May 2019 21:22:24 +0200 (CEST)
Received: from users-MBP.fritz.box (i59F5CC20.versanet.de [89.245.204.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sy) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTPSA id AC4C5FD4; Tue, 21 May 2019 21:22:23 +0200 (CEST)
Reply-To: sy@informatik.uni-hamburg.de
To: Michael Tuexen <michael.tuexen@lurchi.franken.de>
Cc: tcpm@ietf.org
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>
From: Erik Sy <sy@informatik.uni-hamburg.de>
Openpgp: preference=signencrypt
Autocrypt: addr=sy@informatik.uni-hamburg.de; prefer-encrypt=mutual; keydata= mQENBFdYdRoBCADpTVcxZw2Z+3IEm8QgmYNdzKQdCPnDm3mvV+dskI2vNuhAM7eTHE62Ibl8 TD08JJ0Q5DbaHLZBYZR7dVc6Vw+p5Ns5YM5MpDH4rcJTm9FR/QgJ94dH0dOKwtq9gMhLdlhV N0v/OgDb7YdfNYzhthVc3MUxBEznspDaBsGXCASM98SvCaovrhDU05OyIIq6yaIZc6W1ad8z oLn3kZ1O0NkJFuS2H6W1Sg6+af2980SagRTEntr/U6y9wKrKMr0woPBkgYjjivW31yRpjbW0 FClGr/WamdETrJFMTnn6Zc4tELj4pI5T/3jsSCuJ+Mf0fxGIoznG1xW09E5KoT4RBQZ7ABEB AAG0JkVyaWsgU3kgPHN5QGluZm9ybWF0aWsudW5pLWhhbWJ1cmcuZGU+iQFBBBMBCgArAhsD BQkFo5qABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCV8aJfQIZAQAKCRB4ziXHIWIRJSVz B/wJ1qq82vLrjp+4GOUJf3w23FGK3gtK0THs7VVwtZD+xRGYOzoMG+my0TscPZI5drHnZJeK vYmx+bz0IvJSW9DgYib5kUKtz2qPmj0HR6qW7o5opbIMWmkZJO0ACUEI3pAX+j7O3nEApijT 6dg3XhkLdRBgKVHD6x7n8a0ZbYEta6Co0vmPSpIU8XL1B0MmC9fC/L85kH3MBU0bNA4QU0b+ I9ojylgLnqHhIL39mqpJ/cRfCkuzWeeyFvvD+EGMBVxVKVu7ULNk4sKvqutsoYV6GQ7pAx+O pCKQO87M8aeMF7ytpQ67WGscqCO6IWO5tqDXX3aV9MCswPsuwn+PGjAguQENBFdYdRoBCADQ HO0cmKfEv9y5WW6sXJdnn7PEknFyiI9HoCULGVJi4vWyqYoQBGAM8wWRAVstm8zhqIWTlKR2 EntH6JBQB9dkUtmvuVRBBXs9SSloZU4R7SDysuTmDo3derqbIcomtyTkbfxYI50EQayL8TgR sA6jj9OJzyeywX3c+Nr6G8a0kVvCB97I1qLO5RA1tTIxTiXJMbL+E3CurUIMAakxbuqfH3SV mtH+lmlvGzvUF9mI4a5xti1Jkl/k6p2Q5z3nLt6MgkC9n47BSvrzelIr526FzNTamFIVb4fT /QnC33IydbaVQZaOYD9wi9dHTRBaeAF5a+zY5MCUu17GV3jR36SVABEBAAGJASUEGAECAA8F AldYdRoCGwwFCQWjmoAACgkQeM4lxyFiESV1zwf+PwKloXwIb7450kQq/OukJ90o9jkfGMz1 uC84E/HoYaz8KBUJVmx07zYi0zopAn2Pvh+HtTB6NzoGoRvmvajVa3lWRVeytgtJp+YqdcJq mKa+c1MsrJD2iMr3jMLB70bWT+GA8Moe1Slw4+/c+BndlwnfA5B54PVHjnZtaJDVsyVO1dnj gPReP6YNOQP/AgGexfSqUMYI/ni1QKwMT8e806hc48zT2A1ZnBit5PkGjzvQU0Qoel6Cwj3R uzZJgC5iEdX6kxMEOB0mD6zSKzBg4FNn2r3kUQ24IhbTuMm6/aCv6YlObR8HHkqXcQF6/BTH jlkuqsjIxOXZXqe4DeUnhw==
Message-ID: <a6411190-fc9c-3f4d-470d-796023f68a1e@informatik.uni-hamburg.de>
Date: Tue, 21 May 2019 21:22:20 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <090B342F-960D-4F0D-ABF4-5E29E6BAF2AA@lurchi.franken.de>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/U7KP70ksWCfXhIk9xmN1MdR6G5E>
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: Tue, 21 May 2019 19:22:36 -0000

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.
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.

>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
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
>>
>>