Subject: [tcpm] Privacy problems of TCP Fast Open

From: Erik Sy <[email-masked]>
Date: Fri, 10 May 2019 14:14:46 +0200

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

---

From: Erik Sy <[email-masked]>
Date: Mon, 20 May 2019 23:19:26 +0200

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.

Regards,
Erik

On 5/10/19 14:14, Erik Sy wrote:

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 21 May 2019 09:13:11 +0200

> On 20. May 2019, at 23:19, Erik Sy <[email-masked]> wrote:
> 
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

---

From: Erik Sy <[email-masked]>
Date: Tue, 21 May 2019 09:52:09 +0200

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

---

From: Michael Welzl <[email-masked]>
Date: Tue, 21 May 2019 11:39:55 +0200

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?

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 <[email-masked]> wrote:
> 
> Hi Michael,
>

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 21 May 2019 12:18:48 +0200

> On 21. May 2019, at 09:52, Erik Sy <[email-masked]> wrote:
> 
> Hi Michael,
> 
How often do the public addresses change? One could extend the TFO API in
a way that the application can request a new cookie by only sending 
a cookie request.
> 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.

Best regards
Michael

---

From: Erik Sy <[email-masked]>
Date: Tue, 21 May 2019 14:25:24 +0200

On 5/21/19 12:18, Michael Tuexen wrote:
> 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.
Additionally, I can initiate a change of my network's public IP address
at anytime.

TFO cookies allow basically unlimited tracking periods because they do
not have an expiration mechanism. Thus, even infrequently changed IP
addresses can be correlated.

>  One could extend the TFO API in

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.

> But using TFO in that case doesn't

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

---

From: Brian Trammell (IETF) <[email-masked]>
Date: Tue, 21 May 2019 14:47:58 +0000

hi Michael,

Further foolishness inside ;)

> On 21 May 2019, at 09:39, Michael Welzl <[email-masked]> wrote:
> 
> Hi all,
> 

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.

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

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

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 21 May 2019 18:27:59 +0200

> On 21. May 2019, at 11:39, Michael Welzl <[email-masked]> wrote:
> 
> Hi all,
> 
Aren't you referring to https://tools.ietf.org/html/rfc7413#section-7.3

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 21 May 2019 18:34:38 +0200

> On 21. May 2019, at 14:25, Erik Sy <[email-masked]> wrote:
> 
> 
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
Sure.
> addresses can be correlated.
An implementation can do implement such a thing and even allow an API for it.
For testing I'm flushing the cookie cache quite often...
> 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?

Best regards
Michael

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 21 May 2019 18:14:07 +0000

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 <[email-masked]> On Behalf Of Brian Trammell
Sent: Tuesday, May 21, 2019 7:48 AM
To: Michael Welzl <[email-masked]>
Cc: Michael Tuexen <[email-masked]>; tcpm IETF list <[email-masked]>
Subject: Re: [tcpm] Privacy problems of TCP Fast Open

hi Michael,

(1) Do nothing.

Cheers,

Brian

>> 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.
>> 
>>>> 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
>>>> 
>>>>> TCP Fast Open has significant privacy problems which are not 
>>>>> considered in RFC 7413.
>>>>> 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.
>>>>> 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
>>>>> 
>>>>> 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
>>>> 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
>> 
>> 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
> 
> 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
[email-masked]
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

---

From: Erik Sy <[email-masked]>
Date: Tue, 21 May 2019 21:22:20 +0200

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

> binding on the access router, why couldn't they trigger flushing the

Flushing the cache presents a performance versus privacy trade off
because flushing increases the chance of a cache miss preventing a 0-RTT
handshake.
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.

>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
application/browser vendor responsible to protect their privacy. Thus,
these vendors require appropriate measures to control their users' privacy.

Best regards,
Erik

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 21 May 2019 21:56:59 +0200

> On 21. May 2019, at 21:22, Erik Sy <[email-masked]> wrote:
> 
> 
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.
> online tracker to link the user's online activities across both browser
Can't they both be linked by the IP address being used?
> 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"?

Best regards
Michael

---

From: Erik Sy <[email-masked]>
Date: Tue, 21 May 2019 22:12:40 +0200

Hi Brian,

On 5/21/19 16:47, Brian Trammell (IETF) wrote:
> 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 (https://eprint.iacr.org/2019/228.pdf)
>  so data sent in 0RTT for TLS1.3 or QUIC has different cryptographic properties than the rest of the session). 
>

As described in the linked paper (https://arxiv.org/pdf/1905.03518.pdf),
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
Erik

---

From: Erik Sy <[email-masked]>
Date: Tue, 21 May 2019 22:51:00 +0200

> 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
connection request allows a more accurate tracking than can be done via
the publicly visible IP addresses.
> How does this prevent "tracking by IP-address" compared to "tracking
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.
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.

Best regards,
Erik

---

From: Michael Welzl <[email-masked]>
Date: Wed, 22 May 2019 00:13:01 +0200

Hi,

See below:

> On May 21, 2019, at 4:47 PM, Brian Trammell <[email-masked]> wrote:
> 
> hi Michael,
> 

Why would 3 require coordinated implementation effort?
Just to make sure we’re on the same page, I’m proposing to allow handing over data from the SYN directly (with all the needed caveats and warnings), even when there’s no TFO option in place.
If a server doesn’t support this yet, it takes an RTT longer. If a client doesn’t support this yet (and hence only puts in data on a SYN *with* the TFO option), nothing bad happens, except that there are the privacy concerns that kicked off this thread. When a client doesn’t support this and does *not* put data on a SYN, nothing special happens. This seems like a good gradual upgrade path for me.
Regarding front-ends, I guess they could make rejection decisions when they see too many SYNs carrying data with or without a TFO option.

Perhaps this also answers Michael Tuexen’s comment about  https://tools.ietf.org/html/rfc7413#section-7.3 <https://tools.ietf.org/html/rfc7413#section-7.3>  - which has similarities, but:
- the first paragraph sounds a bit too limiting: I mean this as a general use thing, just like TFO, only with the caveat of having to limit the load somehow… e.g. limit how many of these messages-on-SYNs an app processes per second.
- the second paragraph is in conflict with what I’m proposing: it talks about generating "a trivial or even a zero-length cookie” and switching to regular TFO as a fall-back. I’m proposing operation without a TFO option; just relax the “how to process data from SYN” rule and state all the necessary warnings.

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

Yep, that too… just relaxing the “how to process data-on-SYN" rule seems easier to deploy.

Cheers,
Michael

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 22 May 2019 09:10:22 +0200

Michael, Brian,

> Just to make sure we’re on the same page, I’m proposing to allow handing over data from the SYN directly (with all the needed caveats and warnings), even when there’s no TFO option in place.

During the Prague meeting, Christoph Paasch explained that this approach is already used by a specific application. The 0-rtt convert protocol also proposes to use this approach.

> Regarding front-ends, I guess they could make rejection decisions when they see too many SYNs carrying data with or without a TFO option.

I agree, there are various techniques to deal with DoS attacks on a stack and inside specialised protocols.
> Yep, that too… just relaxing the “how to process data-on-SYN" rule seems easier to deploy.

RFC793 authorises data in the SYN and Christoph’s explanation shows that today SYN with data but without TFO option pass through more paths than SYN with data but with a TFO option

Olivier

-- 

Disclaimer: https://www.tessares.net/mail-disclaimer/ 
<https://www.tessares.net/mail-disclaimer/>

---

From: Erik Sy <[email-masked]>
Date: Wed, 22 May 2019 09:47:23 +0200

Hi Praveen,

> 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

---

From: Praveen Balasubramanian <[email-masked]>
Date: Wed, 22 May 2019 16:07:17 +0000

>> If yes, how do you plan to protect your users against unlimited tracking periods?
Currently by simply not enabling it in InPrivate browsing mode. In future we may expire cookies periodically. FWIW in my observation cookies are expired by servers every few hours.

-----Original Message-----
From: tcpm <[email-masked]> On Behalf Of Erik Sy
Sent: Wednesday, May 22, 2019 12:47 AM
To: Praveen Balasubramanian <pravb=[email-masked]>
Cc: tcpm IETF list <[email-masked]>
Subject: Re: [tcpm] Privacy problems of TCP Fast Open

Hi Praveen,

> 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?
> 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 :-)  

Best regards
Erik

> (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
>
>>> Returning to your example, onion routing does not necessarily 
>>> protect you against tracking via TFO cookies.
>>>
>>> Best regards,
>>> Erik
>>>
>>>> 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 
>>>> 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
>>>>>
>>>>>> https://nam06.safelinks.protection.outlook.com/?url=www.ietf.org&
>>>>>> amp;data=02%7C01%7Cpravb%40microsoft.com%7Cbad41804907040cc48c808
>>>>>> d6de89c701%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636941080
>>>>>> 685657359&amp;sdata=EcBpP%2FOcXZdjtYcaWuPbV%2FUWQrgHYVT8OayLDfPIN
>>>>>> hc%3D&amp;reserved=0%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01
>>>>>> %7Cpravb%
>>>>> w
> oft.com%7Cbad41804907040cc48c808d6de89c701%7C72f988bf86f141af91ab2d7cd
> 011db47%7C1%7C0%7C636941080685657359&amp;sdata=7AcPUzNPsP7BTpH974kFHWl
> ZWSB%2BBKyYqTOEQDMD2II%3D&amp;reserved=0
>
> oft.com%7Cbad41804907040cc48c808d6de89c701%7C72f988bf86f141af91ab2d7cd
> 011db47%7C1%7C0%7C636941080685657359&amp;sdata=7AcPUzNPsP7BTpH974kFHWl
> ZWSB%2BBKyYqTOEQDMD2II%3D&amp;reserved=0

_______________________________________________
tcpm mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40microsoft.com%7Cbad41804907040cc48c808d6de89c701%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636941080685657359&amp;sdata=7AcPUzNPsP7BTpH974kFHWlZWSB%2BBKyYqTOEQDMD2II%3D&amp;reserved=0

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 22 May 2019 19:21:39 +0200

> On 21. May 2019, at 22:51, Erik Sy <[email-masked]> wrote:
> 
> 
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.
> 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.
> 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)?

Best regards
Michael

---

From: Erik Sy <[email-masked]>
Date: Wed, 22 May 2019 21:41:43 +0200

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

> 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

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 22 May 2019 22:25:59 +0200

> On 22. May 2019, at 21:41, Erik Sy <[email-masked]> wrote:
> 
> 
Are you aware of such an implementation? Doesn't that mean that a server
has the capability to differentiate clients behind a NAT to provide different
TFO cookies? If he has the capability, why does he need TFO cookies?
> that can change the publicly visible IP address of it's traffic (similar
OK. So the server sees multiple proxies talking to him. Since the proxies
terminate the TCP connections, the server would not see the TFO cookies,
which were provided by the proxies to the clients.

Best regards
Michael

---

From: Erik Sy <[email-masked]>
Date: Wed, 22 May 2019 23:42:12 +0200

On 5/22/19 22:25, Michael Tuexen wrote:
> Are you aware of such an implementation? 
I did not investigate the default mechanisms different operating systems
use to generate TFO cookies. However, patching a kernel to generate
unique TFO cookies for connections from the same IP address is certainly
feasible for online trackers. For example, one can use an truncated hash
of the client's IP address appended by a counter to construct such a
unique cookies.
> Doesn't that mean that a server

No. Let's assume we have two clients behind a NAT with the same public
IP address. The first client receives a unique TFO cookie during its
first connection. When this client reconnects to the server, it will
present the cookie received during it's first connection. This allows
the server to conclude that both connection originate from the same host
because this cookie was only issued a single time. The second client
will receive a different TFO cookie during it's first connection. Thus,
both clients can be clearly differentiated by the server.

> which were provided by the proxies to the clients.
There exist different types of proxies. I thought of gateways/
tunnelling proxies that only change the publicly visible IP address
similar to onion routing. Thus, the client's TFO cookie will be
forwarded to the server.

Best regards,
Erik

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 23 May 2019 22:06:09 +0200

> On 22. May 2019, at 23:42, Erik Sy <[email-masked]> wrote:
> 
> 
Sure. But this can always be done by the issuer of the cookie. Or am I missing
something?
> both clients can be clearly differentiated by the server.
As said above: If the issuer of the cookie wants to do that, it is possible.
This is a consequence of of using a cookie mechanism.

As far as I know, neither Linux nor FreeBSD build the cookie in a way to
send you different ones for different clients behind a NAT.

Best regards
Michael