Re: A question about user tracking with QUIC

Stephane Bortzmeyer <bortzmeyer@nic.fr> Mon, 07 June 2021 19:03 UTC

Return-Path: <stephane@sources.org>
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 58D633A41DA for <quic@ietfa.amsl.com>; Mon, 7 Jun 2021 12:03:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Level:
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 cyX7Aic0EfBQ for <quic@ietfa.amsl.com>; Mon, 7 Jun 2021 12:03:08 -0700 (PDT)
Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [92.243.4.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A690E3A41BF for <quic@ietf.org>; Mon, 7 Jun 2021 12:03:08 -0700 (PDT)
Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id B972AA026A; Mon, 7 Jun 2021 21:03:06 +0200 (CEST)
Received: by mail.sources.org (Postfix, from userid 1000) id 1F139190B87; Mon, 7 Jun 2021 20:58:59 +0200 (CEST)
Date: Mon, 07 Jun 2021 20:58:59 +0200
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Cc: Stephane Bortzmeyer <bortzmeyer@nic.fr>, Lucas Pardue <lucaspardue.24.7@gmail.com>, IETF QUIC WG <quic@ietf.org>, Robin MARX <robin.marx=40uhasselt.be@dmarc.ietf.org>
Subject: Re: A question about user tracking with QUIC
Message-ID: <20210607185858.GB5394@sources.org>
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> <7801F15A-BB23-4EDB-A1BC-DF4DDCF8D204@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7801F15A-BB23-4EDB-A1BC-DF4DDCF8D204@gmail.com>
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 10.9
X-Charlie: Je suis Charlie
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/iVQpzqPn2ZU9PUHH690gTqljoPY>
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 19:03:21 -0000

On Mon, Jun 07, 2021 at 04:36:57PM +0200,
 Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> 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.