Re: A question about user tracking with QUIC

Lucas Pardue <lucaspardue.24.7@gmail.com> Tue, 08 June 2021 02:19 UTC

Return-Path: <lucaspardue.24.7@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 7E3D43A1C7C for <quic@ietfa.amsl.com>; Mon, 7 Jun 2021 19:19:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 YcvXT1JIryaD for <quic@ietfa.amsl.com>; Mon, 7 Jun 2021 19:19:40 -0700 (PDT)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 03E033A1C7B for <quic@ietf.org>; Mon, 7 Jun 2021 19:19:39 -0700 (PDT)
Received: by mail-ej1-x630.google.com with SMTP id h24so29963559ejy.2 for <quic@ietf.org>; Mon, 07 Jun 2021 19:19:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zRIdlmmY355g6vsj0bFIZVL/dFYIUBWyhUiwv1OcN50=; b=cBf+vmKi5ESLF7IAHYv6Uo2MMwdmPd6udtUV3Ba63UMy1f7cd8ao1A0eM/xraPHOgF 568qV1nco4a9VME56xqXwR9Ez4vwzXcYNFGRttNGh+xb7fxCPg1sW2cpqlMd45SPMt6Z N7jyHVDwqV+htQQIZJ0xZgCEUWuL3gBOjGSmy+zrOjReE/4oiDbJ97avWdApKJ/8qLLG OVDobOCURWz/A2g/RJ4Xespk1ZxLUizX+PGDIWe6F5tyhU8TwXf0SYtv0//dfQyHn6bC XmGKYSps10v1DmoWUpxPrkfbtjJw2Pxti7GsIdK1HMznjAC9195a9vlrOpHF2hMC5zS9 g7ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zRIdlmmY355g6vsj0bFIZVL/dFYIUBWyhUiwv1OcN50=; b=GEu3myTeQO2x3oqDNEuvo1A3L0o8ue/RW5EMIcDvON7JQwYrSZaWW3zylnD/zMlSBi q/rsEQMtemvtIC3pROEaDOvp/1hn32ftuMLsc8xq8+eWh+q/PKIywqoBjP2Z3wLEOht5 hPGvbqgakDky5YrmqPqwJ0BbDV7jsyOtqc65fLBIS13rG1aB2RoskG1bUmGq8UTAWXC6 yKgWlaaVE3mFv08OS2HWDat0Y8PBG3Cq4V4oQpb6JRpCf0bVPgNHTJCk8WvEma5tKF/S e9ZK7nXb5ZVOdYBPePi1tlCyUPAbEtIWbFWn32hmfd2DGskGZHrBeyl3zV02rX+Ik9e7 6BdQ==
X-Gm-Message-State: AOAM5324roTqUXuatvZbYBxsvlFbDRZnSvItUcTtclkREiryCajXGKIH wTXrT19CN5wc+EeKmEv3NvcRRMed8u+R6OS8fm8=
X-Google-Smtp-Source: ABdhPJy24AXe8pFxInVd2a3S2ir6+TzllxmKULto7MULyrXOsV6UWsntPMzHlwmdFtqT/YitTk35K+kZVncReb+Duwo=
X-Received: by 2002:a17:906:5488:: with SMTP id r8mr21143259ejo.374.1623118777585; Mon, 07 Jun 2021 19:19:37 -0700 (PDT)
MIME-Version: 1.0
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> <C1B56269-0EF7-42EC-8824-70F7485807B2@gmail.com> <20210607190027.GC5394@sources.org> <7CE3F7FC-21C1-4519-AA60-A2FDFFC512EE@gbiv.com> <CALGR9oZFbUnZyRnL-TPvMac25cjp9WTReTAHWLGi+eO3_T7aww@mail.gmail.com> <CAKKJt-eLegqkLw8dJzPwpV97wsdw3BXh7M-=P2BoYC=B04pwSA@mail.gmail.com> <8d9bfd40-59c5-286b-f2b6-64d4e552c69e@huitema.net>
In-Reply-To: <8d9bfd40-59c5-286b-f2b6-64d4e552c69e@huitema.net>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Tue, 08 Jun 2021 03:19:26 +0100
Message-ID: <CALGR9oYZUxLmKHt9fxP6Bj11CMiPRfwVr_5Qb-uhnV+moapyrA@mail.gmail.com>
Subject: Re: A question about user tracking with QUIC
To: Christian Huitema <huitema@huitema.net>
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, "Roy T. Fielding" <fielding@gbiv.com>, IETF QUIC WG <quic@ietf.org>, Stephane Bortzmeyer <bortzmeyer@nic.fr>
Content-Type: multipart/alternative; boundary="0000000000002a94f205c437ca26"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/c4oGeLDS7Bcmh3f7d7n5Ne0wLHI>
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: Tue, 08 Jun 2021 02:19:46 -0000

Hey Spencer, Christian,

On Tue, Jun 8, 2021 at 2:58 AM Christian Huitema <huitema@huitema.net>
wrote:

>
> On 6/7/2021 6:50 PM, Spencer Dawkins at IETF wrote:
>
> Hi, Lucas,
>
> On Mon, Jun 7, 2021 at 4:22 PM Lucas Pardue <lucaspardue.24.7@gmail.com> <lucaspardue.24.7@gmail.com>
> wrote:
>
>
> Hi,
>
> Speaking as an individual.
>
> Through the lens of server-side observation and linking of clients, I
> think Christian makes astute observations on some common concerns and
> QUIC-specific ones. Roy too makes some great additional observations about
> the context of discussion.
>
>
> Agreed. Very helpful.
>
>
>
> It seems to me this topic might well do with some time to draw out the
> considerations for documentation. However, the applicability draft is
> already through a second round of WGLC, and that timeline seems too tight
> for inclusion of such considerations. I would seem to me that the PEARG
> (Privacy Enhancements and Assessments Research Group) [1] is ideally suited
> towards housing effort on deeper/broader analysis of privacy aspects of
> protocol evolution (I might even stick a note in for multipath TCP as
> something that moves the needle on privacy of "legacy" application
> protcols).
>
>
> Ignoring the question of PEARG interest in this topic for now, I'm assuming
> that these observations would likely end up in an Informational RFC, is
> that right?
>
> An IRTF RG can publish Informational and Experimental RFCs, but not BCPs or
> standards-track documents that must be published in the IETF stream, so
> that would be an important question to answer early.
>
> That.
>
> The IRTF is not the IETF. IRTF research groups are best for analyzing
> difficult research issues. But if we end up doing something like "privacy
> considerations for QUIC clients", IMHO that belongs in the IETF, not the
> IRTF.
>

Not disagreeing with either of you here. Although perhaps I was thinking
more broadly that QUIC-specific concerns, and something more like "privacy
considerations of long-lived and resumable connections for protocol design
and user agents". This to me would appear to me to fit some of PEARG's
charter goals such as: "Formulate better models for analyzing and
quantifying privacy risks", "Offer guidance on the use of emerging
techniques and new uses of existing ones", and "engage with other
organisations e.g. PETS, SOUPS, W3C and the Privacy Interest Group
therein". Others could disagree with me, and I'd encourage them to express
an opinion so we can figure it all out. I guess I was speculating that the
process of work in an RG might actually help us determine the right type of
text (if anything) that should be written for affected protocols. That
could provide input into concrete consideration for protocol designers or
deployers, best written in an IETF WG. The best place for QUIC work is this
WG.

Cheers,
Lucas