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.
- Re: A question about user tracking with QUIC Robin MARX
- A question about user tracking with QUIC Stephane Bortzmeyer
- Re: A question about user tracking with QUIC Lucas Pardue
- Re: A question about user tracking with QUIC Stephane Bortzmeyer
- Re: A question about user tracking with QUIC Stephane Bortzmeyer
- Re: A question about user tracking with QUIC Mikkel Fahnøe Jørgensen
- Re: A question about user tracking with QUIC Stephane Bortzmeyer
- Re: A question about user tracking with QUIC Mikkel Fahnøe Jørgensen
- Re: A question about user tracking with QUIC Mikkel Fahnøe Jørgensen
- Re: A question about user tracking with QUIC Christian Huitema
- Re: A question about user tracking with QUIC Stephane Bortzmeyer
- Re: A question about user tracking with QUIC Stephane Bortzmeyer
- Re: A question about user tracking with QUIC Stephane Bortzmeyer
- Re: A question about user tracking with QUIC Töma Gavrichenkov
- Re: A question about user tracking with QUIC Roy T. Fielding
- Re: A question about user tracking with QUIC Lucas Pardue
- Re: A question about user tracking with QUIC Spencer Dawkins at IETF
- Re: A question about user tracking with QUIC Christian Huitema
- Re: A question about user tracking with QUIC Lucas Pardue
- Re: A question about user tracking with QUIC Spencer Dawkins at IETF
- Re: A question about user tracking with QUIC Christian Huitema
- IETF hosting vs. Github Stephane Bortzmeyer
- Re: IETF hosting vs. Github Willy Tarreau
- Re: IETF hosting vs. Github Lars Eggert
- Re: IETF hosting vs. Github Willy Tarreau
- Re: A question about user tracking with QUIC Behcet Sarikaya
- Re: A question about user tracking with QUIC Roberto Peon
- Re: A question about user tracking with QUIC Mirja Kuehlewind
- Re: A question about user tracking with QUIC Mirja Kuehlewind