Re: [tcpm] Privacy problems of TCP Fast Open

[Praveen Balasubramanian <[e-mail]>]

We are removing support for TFO only in the InPrivate (incognito) mode of the Edge browser. 

IPv6 privacy addresses mitigate this somewhat. Also, TFO servers will expire the cookies periodically as well. 

I wouldn't be opposed to some expiration scheme on client as well. 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. Also, TFO could also be used on non-public Internet.

Brian a lot of major servers now support TFO. Client support is the problem.

-----Original Message-----
From: tcpm <[e-mail]> On Behalf Of Brian Trammell
Sent: Tuesday, May 21, 2019 7:48 AM
To: Michael Welzl <[e-mail]>
Cc: Michael Tuexen <[e-mail]>; tcpm IETF list <[e-mail]>
Subject: Re: [tcpm] Privacy problems of TCP Fast Open

hi Michael,

Further foolishness inside ;)

> On 21 May 2019, at 09:39, Michael Welzl <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
>>>>> [e-mail]
>>>>> 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
>>>> [e-mail]
>>>> 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
>> [e-mail]
>> 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
> [e-mail]
> 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
[e-mail]
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