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
On 6/7/2021 7:37 AM, Mikkel Fahnøe Jørgensen wrote:
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 protected]> wrote:
On Mon, Jun 07, 2021 at 03:36:31PM +0200,
Mikkel Fahnøe Jørgensen <[email protected]> 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.
