Re: [tcpm] Privacy problems of TCP Fast Open

Erik Sy <sy@informatik.uni-hamburg.de> Wed, 22 May 2019 19:41 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 68BF612016D for <tcpm@ietfa.amsl.com>; Wed, 22 May 2019 12:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 XcKbtUqrRimq for <tcpm@ietfa.amsl.com>; Wed, 22 May 2019 12:41:50 -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 958EF120181 for <tcpm@ietf.org>; Wed, 22 May 2019 12:41:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id 1E78FC96; Wed, 22 May 2019 21:41:48 +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 ouilRxhJxpDI; Wed, 22 May 2019 21:41:47 +0200 (CEST)
Received: from users-MBP.fritz.box (i577BB4AB.versanet.de [87.123.180.171]) (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 1FF9EC95; Wed, 22 May 2019 21:41:44 +0200 (CEST)
Reply-To: sy@informatik.uni-hamburg.de
To: Michael Tuexen <michael.tuexen@lurchi.franken.de>
Cc: tcpm IETF list <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> <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>
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: <2f3a0382-e156-a25f-df34-58946ef488bc@informatik.uni-hamburg.de>
Date: Wed, 22 May 2019 21:41:43 +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: <72266B1A-6103-4602-8087-009A37EC80C5@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/cG3SFwQcfAxlACWR0kCjPnakfwc>
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: Wed, 22 May 2019 19:41:54 -0000

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.

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

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