Re: A question about user tracking with QUIC

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Mon, 07 June 2021 14:37 UTC

Return-Path: <mikkelfj@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305AA3A18B1 for <quic@ietfa.amsl.com>; Mon, 7 Jun 2021 07:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPFaKSlxcQVv for <quic@ietfa.amsl.com>; Mon, 7 Jun 2021 07:37:01 -0700 (PDT)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 204513A16CB for <quic@ietf.org>; Mon, 7 Jun 2021 07:37:00 -0700 (PDT)
Received: by mail-wm1-x336.google.com with SMTP id b145-20020a1c80970000b029019c8c824054so12889598wmd.5 for <quic@ietf.org>; Mon, 07 Jun 2021 07:37:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TW6BpXeFZkKbpkm928E8orB4EL1/PSEiD8CZzNpcnio=; b=WkowcXCAx85mO6ZVMoDdKXIssFEnQGvJ/8pvxNoJK6Sfg/RjxWLfKbibrBZlZ2x+Rn 7BbuzqrXhXseOISh+p4ctsfDCiaE00G5jFfPphjiRjYieq4NxpGCYJZo4WSlwNlRSD1G frBFrn7voJD19FJTjrBGPRhw2ASRPgQpf384N/+f0UHrwaiNLCtXtBeLce4BGgXcvseE uJEmKgeuTHawfZrMVvH4Mp19IG23A58xQ7dSA4gP1P6FJ85yDU8BtkAOnIc38lyMJlNd pur0tJox5B5S/k2YhdFW4M+/Sijew2OOYbJMFfhc8ms9bC0rdSFI/0bFSTWekhLqoHsb a95w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TW6BpXeFZkKbpkm928E8orB4EL1/PSEiD8CZzNpcnio=; b=ciu13GEuYf7XBaHeTQNbF3RSskwUDVZHMTogS9J5X1zM5fn8DmsthdozKQBhl9+6Av 4xDWTrmP7mFPewroWvyw7q7XGPfD+iMoL3+akZPQzvMVS2cl2dL2zS2QgaFdNcHzQvze KNIp5nXBhXTPJtSsRl8mAXLMgHOXDN/83w+rHups7IRSURr8uCZoi83lzjTmNEXjtLMW iVBT5JgSSn22h6eA9jsJKj/VamsZ/crt6dqJ4ohsfAovp7pNLhHqZpviHSaSHn2wVCh0 MKUbZ6rH2NLfEExbfU2bFT8O9ON1gYjzNrR8E6InJTQnhcVxkQael4BjG3HORmjz6R2K 8gIw==
X-Gm-Message-State: AOAM533B2V/c6dyGOkdkBnT+ljn7RNsNGRs2tYtz4PTvoL+gMKFNcs50 LrHA8/ivzE2m24QJuxyOrQk=
X-Google-Smtp-Source: ABdhPJyF1DKD9DxBfrhZUebtjNLFJhA3+7o84wIp9IqIuO8kNgYoZ6M3EPAdpxMlVD+1uqFqhlKbQQ==
X-Received: by 2002:a1c:9dc5:: with SMTP id g188mr17084360wme.141.1623076618935; Mon, 07 Jun 2021 07:36:58 -0700 (PDT)
Received: from [192.168.1.3] ([87.72.40.193]) by smtp.gmail.com with ESMTPSA id k16sm14407548wmr.42.2021.06.07.07.36.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Jun 2021 07:36:58 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: A question about user tracking with QUIC
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <20210607142015.GA31240@sources.org>
Date: Mon, 07 Jun 2021 16:36:57 +0200
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, IETF QUIC WG <quic@ietf.org>, Robin MARX <robin.marx=40uhasselt.be@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7801F15A-BB23-4EDB-A1BC-DF4DDCF8D204@gmail.com>
References: <20210607123854.GA16312@nic.fr> <CAC7UV9bkqOeCgDsCH+Hdq0v=zmRKNNDtpfiq6Ap_vzm5zUzGVg@mail.gmail.com> <CALGR9oZiUe5TyY3Tv432__GH=v+Lpv2EZah0G4ZD+g3E2FkaMg@mail.gmail.com> <20210607130422.GA27971@sources.org> <EE723B6D-7B6B-4B68-A4A1-F1809CF68F1B@gmail.com> <20210607142015.GA31240@sources.org>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/32_CIAfwh1LxiS2cO0K-nUQKmi8>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jun 2021 14:37:05 -0000


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

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.