Subject: A question about user tracking with QUIC

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 7 Jun 2021 14:38:54 +0200

I was thinking about the privacy risks of QUIC and there is one where
I'm not sure what to think of it, and for which I cannot find any
discussion in the archives of the WG.

Long-term QUIC connections may enable some user tracking, even when
the user changes its IP address, without even needing HTTP cookies or
things like that.

I am not sure it is a real problem in practice because it's not new
(HTTP/2 offered similar possibilities), there are many other ways to
track users (HTTP cookies, browser fingerprinting, Google Analytics),
and they even work cross-servers. But it can be a problem for
privacy-oriented technologies (QUIC cannot currently work over Tor but
may be in the future?)

I do not find discussions about that. Was it considered? (If so, you
are welcome to reply "Search with mailarchive yourself" but I prefer
if it comes with URLs and/or approximate datetimes.) Is it, for
instance, a good idea to advise privacy-oriented clients to always
shut down QUIC connections when IP address changes?

---

From: Robin MARX <[email-masked]>
Date: Mon, 7 Jun 2021 14:46:32 +0200

Hello Stephane,

Could you give more (technical) details why you feel long-lived QUIC
connections can allow user tracking, and specifically in the IP-switching
case?

For an on-path attacker observing encrypted QUIC (at one vantage point),
they shouldn't be able to (easily) correlate migrated QUIC connections as
the Connection IDs change during (active) migration.
For an attacker with access to the decrypted payloads, I'm not sure how
QUIC differs from TCP or H3 differs from H2 in your view?

With best regards,
Robin

-- 

dr. Robin Marx
Postdoc researcher - Web protocols
Expertise centre for Digital Media

*Cellphone *+32(0)497 72 86 94

www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 7 Jun 2021 13:52:19 +0100

Hi Stephane,

As Robin says, to survive such client IP changes would require QUIC
connection migration. RFC 9000 Section 9.5 [1] deals with the privacy
implications of migration.

Cheers
Lucas

[1] https://www.rfc-editor.org/rfc/rfc9000.html#section-9.5

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 7 Jun 2021 14:55:54 +0200

On Mon, Jun 07, 2021 at 02:46:32PM +0200,
 Robin MARX <[email-masked]> wrote 
 a message of 127 lines which said:

> For an on-path attacker observing encrypted QUIC

Indeed, I forgot an important thing: tracking BY THE SERVER
(obviously, QUIC protects against an observer).

> QUIC differs from TCP or H3 differs from H2 in your view?

TCP and H2 do not survive IP address change. And I suspect that
long-term connections might be more common with QUIC.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 7 Jun 2021 15:04:22 +0200

On Mon, Jun 07, 2021 at 01:52:19PM +0100,
 Lucas Pardue <[email-masked]> wrote 

> implications of migration.

This section is completely silent about tracking BY THE SERVER. It
only considers a passive observer, which is not the only threat.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 7 Jun 2021 15:36:31 +0200

User tracking has been discussed a lot during the development of the QUIC protocol. That is not say the discussion is no longer relevant, but it has not been ignored.

For servers, it is necessary to track users across migrations, because you need to maintain connection state and to maintain the IP address of where to send data. One could add meta-criteria outside the protocol such as the QUIC application must not extract IP data or other user identifiable data from the stack, but that is not enforceable within the protocol, and it is also not always desirable. For example when having to whitelist users.

On the other hand it is important to not allow servers to track users across different connections. This is complicated because of 0-RTT state being maintained. I think perhaps more work could be done in this area for future versions. On the other hand there is wording in the protocol to prevent external observers from linking different connections to the same user, although it may still be possible through traffic analysis which is also mentioned as a limitation, if I remember correctly.

Mikkel

> On 7 Jun 2021, at 15.04, Stephane Bortzmeyer <[email-masked]> wrote:
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 7 Jun 2021 16:20:16 +0200

On Mon, Jun 07, 2021 at 03:36:31PM +0200,
 Mikkel Fahnøe Jørgensen <[email-masked]> wrote 
 a message of 37 lines which said:

> User tracking has been discussed a lot during the development of the
> QUIC protocol.

User tracking BY THE SERVER? I'm sure the WG left no stone unturned
but I cannot find this discussions in the email archives. I probably
used the wrong keywords.

> For servers, it is necessary to track users across migrations,
> because you need to maintain connection state and to maintain the IP
> address of where to send data.

This is why that I suggested (but it may be a bad idea, may be I
didn't think of everything) that a privacy-conscious client may be
better by not using connection migration, and resetting to an entirely
new connection when the IP address changes.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 7 Jun 2021 16:36:57 +0200

> new connection when the IP address changes.

You cannot do that for non-trivial protocols such as HTTP because you need application state that cannot be interrupted during migration. Even if you create a new connection, the server would still need to know how to connect the new connection to the existing state. You might for example be in the middle of transferring a picture over an HTTP stream when migrating. You would have to drop the picture and restart transfer at the new connection. And it wouldn’t be hard for the server to fingerprint.

You could imagine other more privacy conscious protocols, also over QUIC, but you would have to define your own application protocol, and explicitly disallow connection migration and possibly also 0-RTT. For example, you could create a public FTP like service in this way and restart file download if connection is broken due to user migration. QUIC has a 0 connection ID that disallows migration, so you can do this if you want.

QUIC discussions has mostly focused on the HTTP use case, and general TCP replacement, for version 1, although I and others have also pushed for other use cases such as symmetric server to server communication.

If you really want privacy you can do more than QUIC does, such as onion routing, but that might depend on middleware and require trust to be placed elsewhere. This presumably comes at a cost of latency and complexity which is outside the design scope of QUIC.

You might also want to look into QUIC tunnelling, but I have not studied this in detail.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 7 Jun 2021 16:37:45 +0200

Also note that a lot of dicussions have taken place on github issues and pull requests.

> On 7 Jun 2021, at 16.20, Stephane Bortzmeyer <[email-masked]> wrote:
>

---

From: Christian Huitema <[email-masked]>
Date: Mon, 7 Jun 2021 08:21:24 -0700

I think Stéphane raises an interesting point: QUIC does enable 
trade-offs between privacy and performance, and these trade-offs are not 
well documented in the published RFC. The main trade-off comes from the 
use of session resumption, including 0-RTT. A similar trade-off results 
from using retry tokens provided in NEW TOKEN frames. A secondary 
trade-off comes from the use of connection migration.

Session resumption in QUIC uses the mechanisms described in TLS 1.3. The 
risks is actually documented in RFC 9001, in section 9.1 of the session 
considerations, "Session Linkability". The entire text says: "Use of TLS 
session tickets allows servers and possibly other entities to correlate 
connections made by the same client; see Section 4.5 for details." 
Section 4.5 is the description of the resumption mechanism. The relevant 
text in that section says: "Session resumption allows servers to link 
activity on the original connection with the resumed connection, which 
might be a privacy issue for clients. Clients can choose not to enable 
resumption to avoid creating this correlation. Clients SHOULD NOT reuse 
tickets as that allows entities other than the server to correlate 
connections; see Appendix C.4 
<https://www.rfc-editor.org/rfc/rfc8446#appendix-C.4> of [TLS13 
<https://www.rfc-editor.org/rfc/rfc9001.html#TLS13>]."
<https://www.rfc-editor.org/rfc/rfc9001.html#name-session-linkability>

The session resumption risk is not new to QUIC. This is exactly the same 
issue as resumption of a TCP/TLS session. QUIC does add an additional 
tracking mechanism with the "NEW TOKEN", which is designed to bypass 
source address verification and save one RTT by showing a proof that the 
IP address was already verified. This token could certainly allow some 
form of tracking. We can debate whether this is an additional risk 
compared to the TLS session token, but Stéphane's point hold: this 
trade-off between performance and privacy is not analyzed and documented.

Similarly, there are potential trade-offs with the support of connection 
migration. A client that attempts migration reveals the new IP address 
used for that migration. A client that acts on a "server preferred 
address" parameter may end up using and revealing a new IP address. We 
can argue that the trade-offs are OK, but they are just that, 
trade-off.And they are indeed not documented in the RFC.

There are mitigations to all these risks. For example, the classic 
mitigation for session resumption privacy risk is for the client to not 
use it at all, or to only use it if the IP address did not change and if 
the ticket was provided recently. The same apply for the "NEW TOKEN" 
variants of retry tokens. It is actually hard for clients behind NAT to 
know that their IP address did not change, so such mitigations need 
work. Similarly, there is a worthwhile discussion of migration risks, 
which are different if the client identifies itself to the server at the 
application layer and if it doesn't. It might be a very good idea to 
publish that.

-- Christian Huitema

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 7 Jun 2021 20:49:26 +0200

On Mon, Jun 07, 2021 at 08:21:24AM -0700,
 Christian Huitema <[email-masked]> wrote 
 a message of 211 lines which said:

> QUIC does enable trade-offs between privacy and performance, and
> these trade-offs are not well documented in the published RFC.

Do we think it could be a good addition to
draft-ietf-quic-applicability?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 7 Jun 2021 21:00:27 +0200

On Mon, Jun 07, 2021 at 04:37:45PM +0200,
 Mikkel Fahnøe Jørgensen <[email-masked]> wrote 

> Also note that a lot of dicussions have taken place on github issues

Any specific reference to such a discussion about privacy "against"
the server? I did not find any.

(And having important discussions on a Microsoft platform not
controlled by the IETF is a bad idea, anyway, but I digress.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 7 Jun 2021 20:58:59 +0200

On Mon, Jun 07, 2021 at 04:36:57PM +0200,
 Mikkel Fahnøe Jørgensen <[email-masked]> wrote 
 a message of 36 lines which said:

> > a privacy-conscious client may be better by not using connection
> > migration, and resetting to an entirely new connection when the IP
> > address changes.
> 
> You cannot do that for non-trivial protocols such as HTTP because
> you need application state that cannot be interrupted during
> migration.

Sorry, but this is not true. HTTP/2 and HTTP/1 can be interrupted, and
often are when the underlying TCP connection is reset, for instance
when the IP address changes. Typically, it is up to the application
above to deal with it.

> QUIC has a 0 connection ID that disallows migration, so you can do
> this if you want.

I must confess that I was not aware of this possibility. (Anyway, the
client can always, unilaterally, tear down the connection and start a
new one.) I think this sort of "tricks" could be interesting to write
down in a section "QUIC for very privacy-loving clients" in some
future RFC.

---

From: Töma Gavrichenkov <[email-masked]>
Date: Mon, 7 Jun 2021 22:12:45 +0300

Peace,

On Mon, Jun 7, 2021, 10:04 PM Stephane Bortzmeyer <[email-masked]> wrote:

> new one.)

I believe this is something NoScript (and Brave) developers should strongly
consider enforcing at all the sites where JS isn't turned on explicitly by
the user.  IDK if they're aware of the implications of HTTP/3 deployment,
though.

--
Töma

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 7 Jun 2021 12:42:40 -0700

> the server? I did not find any.

There have been many discussions about session establishment and
reestablishment.  Too many to note. However, "user tracking" is not the
term used when the same server remembers interactions with a single user.
That's more typically referred to as analytics or sessions, not tracking.

There is a relevant concern about multisite tracking on servers that
present a certificate for multiple origins, but that applies to both H2 and H3
and only if the browser chooses to reuse the same session layer across
multiple sites. Regardless, this is nothing compared to a browser's inherent
tracking features that any origin server is capable of directing for the
sake of tracking at the HTML/JS layer.

There was a conscious decision, early on, that QUIC would not attempt to
provide the same features as Tor (or any other sort of privacy broker).
It is simply impossible for a protocol to do a better job at that without
centralizing everything by default, which would then be a far greater danger
to users than individual origin sessions. Using QUIC to communicate with
a user-selected, private intermediary (like Tor) would be much better, I think,
than trying to do the same with H1/TLS or H2/TLS. Or at least it will be once
there is a large number of users using the same protocols.

> controlled by the IETF is a bad idea, anyway, but I digress.)

The IETF does not have the resources to provide a comparable issue tracking
system, let alone one that manages PRs and version control for authors, while
providing extensive search capabilities at the same time. It's a tool.

....Roy

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 7 Jun 2021 22:21:57 +0100

Hi,

Speaking as an individual.

Through the lens of server-side observation and linking of clients, I think
Christian makes astute observations on some common concerns and
QUIC-specific ones. Roy too makes some great additional observations about
the context of discussion.

It seems to me this topic might well do with some time to draw out the
considerations for documentation. However, the applicability draft is
already through a second round of WGLC, and that timeline seems too tight
for inclusion of such considerations. I would seem to me that the PEARG
(Privacy Enhancements and Assessments Research Group) [1] is ideally suited
towards housing effort on deeper/broader analysis of privacy aspects of
protocol evolution (I might even stick a note in for multipath TCP as
something that moves the needle on privacy of "legacy" application
protcols).

Cheers,
Lucas

[1] - https://datatracker.ietf.org/rg/pearg/about/

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 7 Jun 2021 20:50:45 -0500

Hi, Lucas,

On Mon, Jun 7, 2021 at 4:22 PM Lucas Pardue <[email-masked]>
wrote:

> Through the lens of server-side observation and linking of clients, I
> think Christian makes astute observations on some common concerns and

Agreed. Very helpful.

> something that moves the needle on privacy of "legacy" application

Ignoring the question of PEARG interest in this topic for now, I'm assuming
that these observations would likely end up in an Informational RFC, is
that right?

An IRTF RG can publish Informational and Experimental RFCs, but not BCPs or
standards-track documents that must be published in the IETF stream, so
that would be an important question to answer early.

Best,

Spencer

---

From: Christian Huitema <[email-masked]>
Date: Mon, 7 Jun 2021 18:58:48 -0700

On 6/7/2021 6:50 PM, Spencer Dawkins at IETF wrote:
> Hi, Lucas,
>
> On Mon, Jun 7, 2021 at 4:22 PM Lucas Pardue<[email-masked]>
> wrote:
>
>> Hi,
>>

That.

The IRTF is not the IETF. IRTF research groups are best for analyzing 
difficult research issues. But if we end up doing something like 
"privacy considerations for QUIC clients", IMHO that belongs in the 
IETF, not the IRTF.

-- Christian Huitema

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 8 Jun 2021 03:19:26 +0100

Hey Spencer, Christian,

On Tue, Jun 8, 2021 at 2:58 AM Christian Huitema <[email-masked]>
wrote:

> On Mon, Jun 7, 2021 at 4:22 PM Lucas Pardue <[email-masked]> <[email-masked]>
> wrote:
>
>
> Hi,
>
> difficult research issues. But if we end up doing something like "privacy
> considerations for QUIC clients", IMHO that belongs in the IETF, not the
> IRTF.
>

Not disagreeing with either of you here. Although perhaps I was thinking
more broadly that QUIC-specific concerns, and something more like "privacy
considerations of long-lived and resumable connections for protocol design
and user agents". This to me would appear to me to fit some of PEARG's
charter goals such as: "Formulate better models for analyzing and
quantifying privacy risks", "Offer guidance on the use of emerging
techniques and new uses of existing ones", and "engage with other
organisations e.g. PETS, SOUPS, W3C and the Privacy Interest Group
therein". Others could disagree with me, and I'd encourage them to express
an opinion so we can figure it all out. I guess I was speculating that the
process of work in an RG might actually help us determine the right type of
text (if anything) that should be written for affected protocols. That
could provide input into concrete consideration for protocol designers or
deployers, best written in an IETF WG. The best place for QUIC work is this
WG.

Cheers,
Lucas

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 7 Jun 2021 21:51:25 -0500

Hi, Lucas,

> deployers, best written in an IETF WG. The best place for QUIC work is this

This all seems very reasonable to me. The other question is about timing -
how urgent do people think this guidance is?

Christian characterized "if you don't want to be tracked when you migrate,
you probably shouldn't migrate" as a classic mitigation, and I'm also
wondering if we still have the classic level of concern about traceability.
If our level of concern has been increasing, that might make things more
urgent. But as you said, it's good for us to encourage other people to
express an opinion.

Best,

Spencer

---

From: Christian Huitema <[email-masked]>
Date: Mon, 7 Jun 2021 22:09:04 -0700

> how urgent do people think this guidance is?
I am not sure about that. The most urgent issue is the tracking via TLS 
session tickets, but that's exactly the same issue as TLS over TCP, it 
has been known for ages, and I am confident that browser developers are 
well aware of it. So the sky is not exactly falling.
> urgent. But as you said, it's good for us to encourage other people to

Well, yes, but if instead of migrating the client starts a new session 
using a different IP address and use a session resumption ticket to 
speed up the process, it has not accomplished much. Same issue, if the 
client starts a new session using a different IP address and immediately 
identifies itself by entering a password or providing a cookie. So there 
is a bit of triage to be done between the cases. In the "logged on" 
case, the client is not in a position to avoid tracking. It could just 
as well migrate and enjoy the lower latency. But then, is there much 
real use of migration outside of "long connections in which the client 
has logged on the server?"

Then there is the NAT rebinding case. The client does not voluntarily 
migrate, and the server just observes the packets coming from a new 
address. Too late to hide that, not much point in closing the session in 
the name of privacy.

If clients really want to achieve address privacy and hide their 
location from a server on which they are often logged for long sessions, 
I think they should use a proxy or a VPN. Maybe we should discuss the 
trade-off of that too. And the various javascript APIs that surveillance 
scripts can use to ping servers outside the VPN and do some kind of 
triangulation. I hear that the Web RTC API have a rich surface for that.

All that can become very confusing very quickly, which is why I think 
there is value in teasing out the scenarios and the various trade-offs.

-- Christian Huitema

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 8 Jun 2021 09:42:16 +0200

On Mon, Jun 07, 2021 at 12:42:40PM -0700,
 Roy T. Fielding <[email-masked]> wrote 
 a message of 45 lines which said:

> The IETF does not have the resources to provide a comparable issue
> tracking system, let alone one that manages PRs and version control
> for authors, while providing extensive search capabilities at the
> same time. It's a tool.

The IETF has a budget of ten million US dollars
<https://www.ietf.org/blog/ietf-2021-draft-budget/> and cannot
self-host a Gitlab or a Gitea? It is hard to believe.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 8 Jun 2021 10:40:39 +0200

Stéphane,

> self-host a Gitlab or a Gitea? It is hard to believe.

Like Roy said, it's a tool. I personally don't like it much essentially
for UI concerns which I find difficult to use and sadly, these trouble
were replicated by their competitors, but what I like even less is having
to deal with plenty of accounts everywhere. Github, like it or not, has
become a de-facto standard and plenty of people active in the HTTP
ecosystem already have an account on it, which fluidifies interactions
compared to another approach where one will always have to ask "what's
my account again?".

I personally don't care about what tools the IETF (and the WG) are using,
I'm pretty sure that the various tools run on servers built by large
companies, running processors, RAM and storage designed and built by
other large companies, and that data are transmitted over wires/fibers
also operated by various large companies, maybe even encrypted and signed
using certificates issued by large companies. As long as the service is
delivered, that's what matters to me.

One concern could be that all discussions in issues would need to be
archived though (I don't know if they are nor how to do that). Because
my personal feeling is that while relying more on issues has significantly
improved the focus and reduced bikeshedding, it has also significantly
reduced exposure to certain points, and we don't have the archives of
these discussions anymore in our respective mailboxes. But this is
something unrelated to the tools but to the process, and Gitlab or any
other tool wouldn't change anything to this.

Regards,
Willy

---

From: Lars Eggert <[email-masked]>
Date: Tue, 8 Jun 2021 12:31:54 +0300

Hi,

On 2021-6-8, at 11:40, Willy Tarreau <[email-masked]> wrote:
> archived though (I don't know if they are nor how to do that).

we archive issue discussions by having them forwarded to this mailing list: https://www.ietf.org/mailman/listinfo/quic-issues

> Because
> these discussions anymore in our respective mailboxes.

You can subscribe to the list above, and then you do have things in your own mailbox, or you can search the issues list at https://mailarchive.ietf.org/arch/browse/quic-issues/. (You can of course also search the issues directly on GitHub.)

Thanks,
Lars

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 8 Jun 2021 11:50:10 +0200

Hi Lars!

On Tue, Jun 08, 2021 at 12:31:54PM +0300, Lars Eggert wrote:
> we archive issue discussions by having them forwarded to this mailing list:
> https://www.ietf.org/mailman/listinfo/quic-issues

Ah excellent, so my only minor concern about the process is addressed :-)

Thanks!
Willy

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 8 Jun 2021 09:52:44 -0500

> considerations for QUIC clients", IMHO that belongs in the IETF, not the

+1

Behcet

---

From: Roberto Peon <[email-masked]>
Date: Tue, 8 Jun 2021 19:37:45 +0000

It isn’t just about connections, though.
Connections are just one example of resumable sessions.
The things to worry about apply to all resumable sessions.

-=R

From: QUIC <[email-masked]> on behalf of Lucas Pardue <[email-masked]>
Date: Monday, June 7, 2021 at 7:20 PM
To: Christian Huitema <[email-masked]>
Cc: "Roy T. Fielding" <[email-masked]>, IETF QUIC WG <[email-masked]>, Stephane Bortzmeyer <[email-masked]>, Spencer Dawkins at IETF <[email-masked]>
Subject: Re: A question about user tracking with QUIC

Hey Spencer, Christian,

On Tue, Jun 8, 2021 at 2:58 AM Christian Huitema <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Lucas,

On Mon, Jun 7, 2021 at 4:22 PM Lucas Pardue <[email-masked]><mailto:[email-masked]>

wrote:

Hi,

Agreed. Very helpful.

protcols).

that right?

That.

The IRTF is not the IETF. IRTF research groups are best for analyzing difficult research issues. But if we end up doing something like "privacy considerations for QUIC clients", IMHO that belongs in the IETF, not the IRTF.

Not disagreeing with either of you here. Although perhaps I was thinking more broadly that QUIC-specific concerns, and something more like "privacy considerations of long-lived and resumable connections for protocol design and user agents". This to me would appear to me to fit some of PEARG's charter goals such as: "Formulate better models for analyzing and quantifying privacy risks", "Offer guidance on the use of emerging techniques and new uses of existing ones", and "engage with other organisations e.g. PETS, SOUPS, W3C and the Privacy Interest Group therein". Others could disagree with me, and I'd encourage them to express an opinion so we can figure it all out. I guess I was speculating that the process of work in an RG might actually help us determine the right type of text (if anything) that should be written for affected protocols. That could provide input into concrete consideration for protocol designers or deployers, best written in an IETF WG. The best place for QUIC work is this WG.

Cheers,
Lucas