Re: [tcpm] Privacy problems of TCP Fast Open

Erik Sy <> Tue, 21 May 2019 20:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0FCA41200EC for <>; Tue, 21 May 2019 13:12:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U8NulnKsDiQz for <>; Tue, 21 May 2019 13:12:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5C85E120088 for <>; Tue, 21 May 2019 13:12:45 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7993988E; Tue, 21 May 2019 22:12:43 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id PT5iuDK6Lu-Z; Tue, 21 May 2019 22:12:42 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sy) by (Postfix) with ESMTPSA id F24A288D; Tue, 21 May 2019 22:12:41 +0200 (CEST)
To: "Brian Trammell (IETF)" <>
Cc: tcpm IETF list <>
References: <> <> <> <> <> <>
From: Erik Sy <>
Openpgp: preference=signencrypt
Autocrypt:; 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: <>
Date: Tue, 21 May 2019 22:12:40 +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: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <>
Subject: Re: [tcpm] Privacy problems of TCP Fast Open
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 May 2019 20:12:48 -0000

Hi Brian,

On 5/21/19 16:47, Brian Trammell (IETF) wrote:
> hi Michael,
> Further foolishness inside ;)
>> On 21 May 2019, at 09:39, Michael Welzl <> 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,
Technically 0-RTT does allow forward security and hopefully some of this
research will find its way into TLS (
>  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).

As described in the linked paper (,
my measurements indicate that 3.2% of the Alexa Top Million Sites
support TFO. Thus, only a few people on the Internet run TFO. However,
most clients including Firefox and Chrome do not support TFO by default.
As a result, the TFO traffic share on the Internet is approximately far
below 3.2%.

Best regards

> 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 <> 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 <> 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:
>>>>>> I suggest, that the working group takes steps to highlight these privacy
>>>>>> problems of RFC 7413.
>>>>>> Regards,
>>>>>> Erik
>>>>>> _______________________________________________
>>>>>> tcpm mailing list
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>> _______________________________________________
>>> tcpm mailing list
>> _______________________________________________
>> tcpm mailing list