Re: [tcpm] Privacy problems of TCP Fast Open

[Michael Tuexen <[e-mail]>]

> On 21. May 2019, at 11: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?
Aren't you referring to https://tools.ietf.org/html/rfc7413#section-7.3

Best regards
Michael
> 
> 
> 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?
> 
> 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?"
> 
> 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://arxiv.org/pdf/1905.03518.pdf
>>>>> 
>>>>> I suggest, that the working group takes steps to highlight these privacy
>>>>> problems of RFC 7413.
>>>>> 
>>>>> Regards,
>>>>> Erik
>>>>> 
>>>>> _______________________________________________
>>>>> tcpm mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>> _______________________________________________
>>>> tcpm mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/tcpm
>> 
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>