Re: [tcpm] Privacy problems of TCP Fast Open

Erik Sy <sy@informatik.uni-hamburg.de> Wed, 22 May 2019 07:47 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 BB28B1200FE for <tcpm@ietfa.amsl.com>; Wed, 22 May 2019 00:47:31 -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 FTY6_4BR0ym9 for <tcpm@ietfa.amsl.com>; Wed, 22 May 2019 00:47:27 -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 8C42C1200E6 for <tcpm@ietf.org>; Wed, 22 May 2019 00:47:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailhost.informatik.uni-hamburg.de (Postfix) with ESMTP id B3A11F6C; Wed, 22 May 2019 09:47:25 +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 woOOd0ly1Y3I; Wed, 22 May 2019 09:47:25 +0200 (CEST)
Received: from svs26.informatik.uni-hamburg.de (svs26.informatik.uni-hamburg.de [134.100.15.26]) (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 590C0F6B; Wed, 22 May 2019 09:47:24 +0200 (CEST)
Reply-To: sy@informatik.uni-hamburg.de
To: Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>
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> <7B148CBB-3D8A-4D29-BCA7-0B241E548D4E@ifi.uio.no> <491A06E5-1D3C-46BF-B682-FBFB9B752906@trammell.ch> <MW2PR2101MB104947CF1DF2DF1D06161ECAB6070@MW2PR2101MB1049.namprd21.prod.outlook.com>
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: <a5fe63dc-60ee-ecdb-7e92-fc81e6b2c287@informatik.uni-hamburg.de>
Date: Wed, 22 May 2019 09:47:23 +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: <MW2PR2101MB104947CF1DF2DF1D06161ECAB6070@MW2PR2101MB1049.namprd21.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/w6xGzfT7D2e8SzMat8ropnbxO4s>
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 07:47:32 -0000

Hi Praveen,

On 5/21/19 20:14, Praveen Balasubramanian wrote:
> We are removing support for TFO only in the InPrivate (incognito) mode of the Edge browser.
I'm happy to hear this :-)
> IPv6 privacy addresses mitigate this somewhat.

Let's say IPv6 addresses allow unique user identification for usually up
to 24 hours. Thus, the additional privacy harm of TFO cookies is rather
small.

Do you support TFO cookies on IPv4 addresses? If yes, how do you plan to
protect your users against unlimited tracking periods?

>  Also, TFO servers will expire the cookies periodically as well.
This does not protect against this tracking mechanism. Server and
network-based tracker can correlate the presented (invalid) TFO cookie
with a subsequently issued TFO cookies.
> I wouldn't be opposed to some expiration scheme on client as well.
The deployment of such kernel patches takes several years. How do you
plan to protect the user's privacy during this transition period?
>  And I am fine with adding some guidance around this. If TFO is to become a standards track RFC, then I agree that these concerns should be addressed. 
>
> Let's not overreact and deprecate the only path we have for low latency setup on TCP. 
Achieving low latency TCP connection establishments is a noble goal. The
Internet changed a lot during the last years with transport encryption
becoming the new default. We can use this as a chance to improve TFO
with respect to its privacy, performance and deployment. A
state-of-the-art TFO version will not be downwards compatible with
today's TFO. I suggest to stop the experiment of RFC 7413 and apply the
lessons learned to make the Internet work better :-)  
> Also, TFO could also be used on non-public Internet.

I guess, you can run anything on non-public Intenet ;-)

Best regards
Erik

>
> Brian a lot of major servers now support TFO. Client support is the problem.
> -----Original Message-----
> From: tcpm <tcpm-bounces@ietf.org>; On Behalf Of Brian Trammell
> Sent: Tuesday, May 21, 2019 7:48 AM
> To: Michael Welzl <michawe@ifi.uio.no>;
> Cc: Michael Tuexen <michael.tuexen@lurchi.franken.de>;; tcpm IETF list <tcpm@ietf.org>;
> Subject: Re: [tcpm] Privacy problems of TCP Fast Open
>
> hi Michael,
>
> Further foolishness inside ;)
>
>> On 21 May 2019, at 09:39, Michael Welzl <michawe@ifi.uio.no>; wrote:
>>
>> Hi all,
>>
>> I'm about to make a fool of myself because I'm quite certain that I'm missing something.
>> But, I guess this is worth the risk - somehow I'm not risking much, as most people on this list already know me well enough to not be surprised by another foolish idea coming from me   :)
>>
>>
>> So...
>>
>>
>> Actually, couldn't we just remove the cookie from TFO?
>>
>>
>> As far as I understand, the main point of the cookie is to protect the server against clients that might spoof their IP addresses and just send tons of requests to the server - which could potentially be much heavier to handle than just the SYN state without TFO.
>> To some degree, this is an OS problem, not a network problem: methods could be in place to limit the time an application spends answering requests that are carried on SYNs. My question is: wouldn't that be enough?
> All simple cookie based-approaches have a pretty simple tradeoff: use a cookie which references some previous visible exchange between client and server, trading off load reduction on the server (and flexibility in deployment of DoS protection in front of the server) for traceability (which, in this case, is a requirement, not something to be avoided). The design of TFO (and SYN cookies before it). 
>
> More advanced 0RTT tokens have a different tradeoff; since the token is established between client and server without being observable on the path, here we gain traceability protection and retain server load reduction, but give up the ability to have front-ends that can reject attack traffic without some form of coordination with the server.
>
>> A few years ago, I'm sure that such a proposal would have been shot by people saying that data carried by TCP is general and TCP must serve all applications, and that we can't have that kind of special treatment for data arriving via SYNs.
>> However, TFO has already departed from this generality, in several ways: applications using it must be able to handle incoming duplicate requests; they need to use special API calls to access the data; importantly (for the point I'm making), rate limits should already be in place when using TFO (RFC 7413, section 5.1).
>>
>> So what I'm proposing is: couldn't we re-write TFO to just remove the Cookie from it, and say: "it's allowed for applications to accept data that comes with a SYN right away, but this must be done in a special way (as already described in RFC 7413), and in particular, the time an application spends processing TFO requests must be limited to avoid being DDoSed?"
> You're correct to point out that 0RTT resumption is and will always remain special, not only due to the special requirements it places on applications but also for cryptographic reasons (0RTT cannot be made forward-secret, so data sent in 0RTT for TLS1.3 or QUIC has different cryptographic properties than the rest of the session). 
>
> ISTM there are the following possibilities:
>
> (1) Do nothing.
>
> (1a) Do nothing, but issue guidance in an informational RFC notinf that TFO cookies are traceable, and should be avoided in the open Internet when 
>
> (2) Deprecate TFO (and hope people who want 0RTT migrate to QUIC); explain the privacy reason behind the deprecation in the deprecated document.
>
> (3) Update TFO to make TFO cookies optional, and explain the tradeoffs.
>
> I would expect pushback on 2 or 3 from people running TFO on the Internet, because it requires coordinated implementation effort and changes the operational environment (which always carries risk).
>
> There is the caveat that I'm not sure how many are running TFO on the Internet. (I do know Google was the biggest one, at least a couple of years ago, from research I did before joining).
>
> Cheers,
>
> Brian
>
>> If a server is overloaded and can't process any more TFO data, the result could be that it just doesn't answer at all, and the client would then retransmit the SYN, just as if the SYN had been dropped.
>>
>>
>> Cheers,
>> Michael
>>
>>
>>
>>> 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.
>>>
>>> Returning to your example, onion routing does not necessarily protect 
>>> you against tracking via TFO cookies.
>>>
>>> Best regards,
>>> Erik
>>>
>>> On 5/21/19 09:13, Michael Tuexen wrote:
>>>>> On 20. May 2019, at 23:19, Erik Sy <sy@informatik.uni-hamburg.de>; wrote:
>>>>>
>>>>> I think it is important to warn users about the privacy risks of 
>>>>> RFC 7413. For example, Mozilla reacted to the privacy problems of 
>>>>> TCP Fast Open by deprecating this protocol on all it's Firefox 
>>>>> branches. In total, TCP Fast Open has significant issues with 
>>>>> respect to user privacy, performance and deployment on the 
>>>>> real-world Internet. From my point of view, it is about time to deprecate RFC 7413.
>>>> Hi Eric,
>>>>
>>>> my understanding is that a cookie is specific to a client address, a 
>>>> server address and a server port. So it would make sense for a 
>>>> client to remove entries from the cookie cache on an address change. 
>>>> Assuming that, how does your described host based attacks relate to 
>>>> the server just using the client IP address for tracking? If you are 
>>>> trying to hide you IP-address (like using a TOR browser) you don't 
>>>> want to use TFO, but you are not optimising for small RTTs in that case, so it makes no sense in that case.
>>>>
>>>> Best regards
>>>> Michael
>>>>> Regards,
>>>>> Erik
>>>>>
>>>>> On 5/10/19 14:14, Erik Sy wrote:
>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> TCP Fast Open has significant privacy problems which are not 
>>>>>> considered in RFC 7413.
>>>>>> For example, this protocol allows a passive network observer to 
>>>>>> correlate connections established by the same client, which 
>>>>>> protocols such as TLS 1.3 and QUIC actively protect against. 
>>>>>> Furthermore, Fast Open cookies present a kernel-based tracking 
>>>>>> mechanism which is quite persistent. Amongst others, they can be 
>>>>>> used to conduct cross-browser tracking on the same operating system.
>>>>>> For further details please refer to this article:
>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>> arxiv.org%2Fpdf%2F1905.03518.pdf&amp;data=02%7C01%7Cpravb%40micros
>>>>>> oft.com%7Cc8f0e624868541da87c808d6ddfb5d71%7C72f988bf86f141af91ab2
>>>>>> d7cd011db47%7C1%7C1%7C636940469018140114&amp;sdata=dkgWLSFZYKENl7l
>>>>>> scesJExW6SbZCGfOUXEN8oPHWh2k%3D&amp;reserved=0
>>>>>>
>>>>>> I suggest, that the working group takes steps to highlight these 
>>>>>> privacy problems of RFC 7413.
>>>>>>
>>>>>> Regards,
>>>>>> Erik
>>>>>>
>>>>>> _______________________________________________
>>>>>> tcpm mailing list
>>>>>> tcpm@ietf.org
>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>> www.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%
>>>>>> 40microsoft.com%7Cc8f0e624868541da87c808d6ddfb5d71%7C72f988bf86f14
>>>>>> 1af91ab2d7cd011db47%7C1%7C1%7C636940469018140114&amp;sdata=05KZ4W%
>>>>>> 2BrEPGOmzC0zUf4KGYQWicR%2BS7%2F3VKYXvlizj4%3D&amp;reserved=0
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>>>> tcpm@ietf.org
>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw
>>>>> ww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40
>>>>> microsoft.com%7Cc8f0e624868541da87c808d6ddfb5d71%7C72f988bf86f141af
>>>>> 91ab2d7cd011db47%7C1%7C1%7C636940469018140114&amp;sdata=05KZ4W%2BrE
>>>>> PGOmzC0zUf4KGYQWicR%2BS7%2F3VKYXvlizj4%3D&amp;reserved=0
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm@ietf.org
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>>> .ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40micr
>>> osoft.com%7Cc8f0e624868541da87c808d6ddfb5d71%7C72f988bf86f141af91ab2d
>>> 7cd011db47%7C1%7C1%7C636940469018140114&amp;sdata=05KZ4W%2BrEPGOmzC0z
>>> Uf4KGYQWicR%2BS7%2F3VKYXvlizj4%3D&amp;reserved=0
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>> ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40micros
>> oft.com%7Cc8f0e624868541da87c808d6ddfb5d71%7C72f988bf86f141af91ab2d7cd
>> 011db47%7C1%7C1%7C636940469018140114&amp;sdata=05KZ4W%2BrEPGOmzC0zUf4K
>> GYQWicR%2BS7%2F3VKYXvlizj4%3D&amp;reserved=0
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40microsoft.com%7Cc8f0e624868541da87c808d6ddfb5d71%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636940469018140114&amp;sdata=05KZ4W%2BrEPGOmzC0zUf4KGYQWicR%2BS7%2F3VKYXvlizj4%3D&amp;reserved=0
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm