
Privacy implications of the QUIC protocol [pdf] - ivanblagdan
https://petsymposium.org/2019/files/papers/issue3/popets-2019-0046.pdf
======
3xblah
"The source-address token is a unique, authenticated-encrypted data block
provided by the server, which cannot be decrypted by the client. For the
purpose of IP address spoofing prevention, _it contains the users publicly
visible IP address_ and a timestamp as seen by the server."

Compare ...

[http://curvecp.org/security.html](http://curvecp.org/security.html)

"Does CurveCP provide client address authentication?

No. IP addresses are not secure in any meaningful sense, and CurveCP does not
attempt to make them secure. Servers that distinguish between clients must do
so on the basis of _long-term client public keys, not IP addresses_."

Users can create new public keys anytime they want. They could, e.g., create
one key for one purpose and another for another purpose. Over the years, I
have noticed a common theme in the design of all djb software. Whether it is
intentional or not, I do not know. Control rests with the user.

~~~
tialaramex
So, I think you've completely misunderstood what's going on here.

What QUIC is doing here is to prevent _spoofing_, whereas what DJB is talking
about is the futility of using IP addresses as _identity_

Why does this matter? QUIC servers often have lots of bandwidth available to
them and offer 0-RTT, so they can be used for an amplified denial-of-service
attack. Bad Guys send packets "from" your IP address to the QUIC server.
Without spoofing protection the QUIC server begins bombarding your IP address
with stuff. Your network links saturate and you're effectively knocked out
even though you did nothing to cause this.

Spoofing protection is provided in TCP (on any vaguely modern OS) but QUIC
doesn't use TCP so it must roll its own protection and that's all this is for.

CurveCP has a 1-RTT setup penalty with a "Cookie" to prevent spoofing. If
somebody wants to track you with CurveCP they'd be just as able to use this
cookie as they would the QUIC "source address token". In both cases you could
throw this away to prevent tracking, at a penalty of reducing performance
because you'll have to do the startup dance all over again.

~~~
3xblah
The paper discusses how source address token might be used in tracking and
thus online advertising services, Google's business.

The online tracking and advertising industry and companies selling to that
industry such as Google believe IP addresses, when combined with other
information, tell something valuable about consumers.

Perhaps users of the "modern web browsers" cannot or will not manually control
generation or storage of source address tokens. Hence the need for papers like
this one, pleading with the organisations controlling the browsers to change
the software. That software is of course written by employees of companies and
parents of companies that are paid directly or indirectly from sales of
internet advertising services.

Probably the folks creating these protocols never thought about the
implications of the design on internet advertising services. However, from the
perspective of people selling internet advertising services, the
association/non-association of IP addresses with public keys seems like it
might be significant, regardless of its intended purpose to the protocol
designers. People buying those online ad services are likely to understand the
potential value of IP address information, e.g., they might think it tells
them something about geo-location. If so, they might also see the added value
in the combination of IP address with a unique identifier.

------
jefftk
The network layer can already be used for tracking in multiple ways, including
HTTPS sessions, ETags, and cached files with identifiers. When browsers
partition the network layer they need to partition connection state as well,
which includes QUIC/HTTP3 state. Safari already does this, and it looks to me
like Chrome and Firefox are doing it too: [https://www.jefftk.com/p/shared-
cache-is-going-away](https://www.jefftk.com/p/shared-cache-is-going-away)

(Disclosure: I work on ads at Google, speaking only for myself)

~~~
ivanblagdan
Yes, theres other ways to be tracked at the network level, sure. I don't see
how that changes the discourse? Beyond the straight technical implications,
isn't it concerning that a single company can roll out its own protocol across
the server and browser stacks, implicating 7% of web traffic? Would it be more
concerning if the same company has certain interest in improving its tracking
and data collection capabilities?

Also, I was expecting to find details around browsers implementing some form
of network level partitioning at that link you posted, but failed. Care to
spell it out for me?

------
DyslexicAtheist
in 2017 _Brave_ disabled it:

 _> Back-story: Brave users reported ads getting past our ad-blocking shields
in previous Chromium versions, beginning with reports of ads displaying on
YouTube.com on October 11, 2016. uBlock Origin users had reported similar
bugs. We discovered during testing that disabling QUIC seemed to stop these
ads. As a result, we pushed an update to disable QUIC in Brave on January 25,
2017. This update appears to have temporarily abated the incoming bug reports
about ads getting past our shields.

...

When we inspected web page traffic via chrome://net-internals, we discovered
that QUIC requests were and still are being used for a majority of Google’s ad
domains, including domains involved with bidding ..._

source: [https://brave.com/quic-in-the-wild/](https://brave.com/quic-in-the-
wild/)

~~~
Already__Taken
Google software uses a google protocol to deliver google services. News at 11.

Is this the problem where we've shot ourselves in the foot securing
communication to the point we can't block adequately now by tempering with
traffic?

~~~
cptskippy
> Is this the problem where we've shot ourselves in the foot securing
> communication

Isn't that the goal? Everyone seems to think Google's innovations are gifts to
the world. They are and always have been solutions to problems Google faces.
The only reasons they're opensourced or community shared are to benefit
Google. Anything beyond that is collateral benefit.

------
tialaramex
This is about Google's QUIC ("gQUIC") and is based on a version from 2018. It
explains in the Related Work section at the end that the IETF QUIC protocol
has different properties.

The trade discussed between keeping information for longer to make everything
faster versus throwing it away frequently to avert tracking is _everywhere_
already. It's in your HTTP/1.1 web browser's Cookie behaviour, it's in the TLS
implementation's resumption feature.

One piece of good news is that in the quest to speed things up putting the
public keys into DNS means it's no longer practical to (as is discussed as a
potential attack in this paper) give each client different keys so you can
identify them that way. Because DNS is cache-based everybody receiving the
same version of the cached data will see the same keys. This isn't a problem
for good guys, everything works, but if your goal was to track people against
their will it's a problem.

~~~
zamadatix
Putting the keys over DNS seems really clever. With DoH are requests bundled
in a single session or is the session stood up and torn down per? I assume
it's the former or this proposal wouldn't have gotten far but I've never
actually bothered to check that far into DoH.

~~~
tialaramex
A DNS query wrapped as HTTP actually makes a canonically good example of a
safe TLS 1.3 0-RTT transaction so in principle you don't need to keep sessions
alive.

In your first (1-RTT) DNS lookup you agree a PSK (a secret key) with the DNS
via DoH server.

On the next DNS via DoH lookup you send only one message, it goes like this:

Hi, it's me again. (The rest of the message is encrypted using the PSK).
Here's a freshness check. I want to ask AAAA? www.google.com and also let's
agree a new key for the next time I do this. Thanks, bye.

The DoH server will probably reply like this:

Hi. (The entire rest of the message is encrypted using the PSK). Here's proof
I'm still me passing your freshness check. AAAA www.google.com answer is
some:ipv6:address and yes, here is a new PSK for next time.

This is the same number of messages back and forth as with traditional UDP DNS
albeit the messages are a little bit bigger now, and so it incurs the same
latency.

Because this is 0-RTT the DoH server can't always be sure if it has seen your
query before (doing this is trivial in a toy system with e.g. one DoH server
on a Linux box but hard at scale with a distributed system). So a bad guy
could replay the query. But, it's just a DNS query so replaying it doesn't
achieve anything useful, and this doesn't help the bad guy learn anything
about the query, they don't get to find out what it said or what the answer
means.

[ Edited to remove mis-remembered DH for resumption, alas TLS 1.3 resumption
PSKs are not forward secret ]

------
superfist
Regarding QUIC and tracking, has anyone heard about MASQUE protocol proposal?

[https://tools.ietf.org/id/draft-schinazi-
masque-01.html](https://tools.ietf.org/id/draft-schinazi-masque-01.html)

any thought on this?

~~~
zamadatix
It's nice in that it enables higher performance than previous "looks like a
standard web server" due to QUIC but other than that there isn't too much to
say. It's just a straw man proposal so the implementation details aren't there
to talk about and it's not a new idea outside of binding to QUIC as the
primary transport.

------
zamadatix
"Survives a browser restart: no" seems to imply any method which tried to use
QUIC alone would be highly unreliable.

