Re: A question about user tracking with QUIC

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Tue, 08 June 2021 01:51 UTC

Return-Path: <spencerdawkins.ietf@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 A85C63A1B87 for <quic@ietfa.amsl.com>; Mon, 7 Jun 2021 18:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 YE-aCS3E6NRB for <quic@ietfa.amsl.com>; Mon, 7 Jun 2021 18:51:14 -0700 (PDT)
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 F197C3A1B83 for <quic@ietf.org>; Mon, 7 Jun 2021 18:51:13 -0700 (PDT)
Received: by mail-yb1-xb29.google.com with SMTP id s107so27849467ybi.3 for <quic@ietf.org>; Mon, 07 Jun 2021 18:51:13 -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=VZBn6xYmqcykL53oJKYgVJpFqLa2p0JwKL6GgJssGN0=; b=dtoRdaj+Rn4x90ZFhFyag7YjijxGOwgDXhP1BU4Rcvv8WVwepkLgxDW8iQY19rMD9x q0U//9/OabiulMvVMb1a9aT9E7W0XQrjtDLf4yyNSUQaOKOwsdbFBq+ZSZpMK+hdcxrs XLiEWJ28QqcMGqBLX+3l5lVb/mexCfJIxVe1hgXhu5F1oyAzpRRwi0qX7bh9qyNte+PX xxN/u7Xg3fWq6bL5+BQXXVsfRT6dxG6303PBtmdZHWFqCst+KJNV7hTeULtlcWiHH4sq HRXuAaqJSqJvUO6bXIuwn0ZNXcwxViMgbn7fnoEG4UF8rK08oMsvaQJROmnZPwMKwSK1 eCBA==
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=VZBn6xYmqcykL53oJKYgVJpFqLa2p0JwKL6GgJssGN0=; b=S1DMOLJt2Oemr3it8B0jl+O416+nZvPYYAF9LQDUxQO1/ZOslH2y7VKWwTNAfpiOrg Yx62gWOu3RseCQiw/cEbUUNGf+ZswLEvuWLyMd4n5TN84BWYtCt+6QUW8kO4VIfp8Yxf AqLdeX2/+ZMMMWRInyxaewhXcOwPiZwYVDMGEvdmfk3txcLM2njj6MHdSrENdDDw8ZhQ d1+8Eq+lxUr1sGAzNE5encl8qt62DO/HY+20orpZxpSuiqYbXTDOw7pur/DmcF2uOXyq ALYZJVWGV4NnRqMU7+4jkMClXXJMaR3IM+Xpz5SHwWJoLTg6CouGP+YN63uib6wpTpf+ /R+Q==
X-Gm-Message-State: AOAM532kLABJQ6dhmsx6Lq5C3O8x7wc2zKJ6tdF6S9oe/5aBFxsiW6hP ABUnmpZ0JZB6Ni4MTm2XNT5VVJ3gCn2SqtbkI24=
X-Google-Smtp-Source: ABdhPJx9e072EVt5X3+9ggzgB1POI1yeqYFGKLJS+qdjcspaEtMaVlvsPIqUvVRtvJ9ITparTbK5T1e6xLcqR6mGXYM=
X-Received: by 2002:a25:3746:: with SMTP id e67mr28629831yba.297.1623117071494; Mon, 07 Jun 2021 18:51:11 -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>
In-Reply-To: <CALGR9oZFbUnZyRnL-TPvMac25cjp9WTReTAHWLGi+eO3_T7aww@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Mon, 07 Jun 2021 20:50:45 -0500
Message-ID: <CAKKJt-eLegqkLw8dJzPwpV97wsdw3BXh7M-=P2BoYC=B04pwSA@mail.gmail.com>
Subject: Re: A question about user tracking with QUIC
To: Lucas Pardue <lucaspardue.24.7@gmail.com>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, IETF QUIC WG <quic@ietf.org>, Stephane Bortzmeyer <bortzmeyer@nic.fr>
Content-Type: multipart/alternative; boundary="00000000000079b06b05c43764a5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/NaEqPsbDoC47te61_LcraHJqySY>
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 01:51:19 -0000

Hi, Lucas,

On Mon, Jun 7, 2021 at 4:22 PM Lucas Pardue <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.

Best,

Spencer


> Cheers,
> Lucas
>
> [1] - https://datatracker.ietf.org/rg/pearg/about/
>
> On Mon, Jun 7, 2021 at 8:43 PM Roy T. Fielding <fielding@gbiv.com> wrote:
>
>> On Jun 7, 2021, at 12:00 PM, Stephane Bortzmeyer <bortzmeyer@nic.fr>
>> wrote:
>> >
>> > Any specific reference to such a discussion about privacy "against"
>> > the server? I did not find any.
>>
>> There have been many discussions about session establishment and
>> reestablishment.  Too many to note. However, "user tracking" is not the
>> term used when the same server remembers interactions with a single user.
>> That's more typically referred to as analytics or sessions, not tracking.
>>
>> There is a relevant concern about multisite tracking on servers that
>> present a certificate for multiple origins, but that applies to both H2
>> and H3
>> and only if the browser chooses to reuse the same session layer across
>> multiple sites. Regardless, this is nothing compared to a browser's
>> inherent
>> tracking features that any origin server is capable of directing for the
>> sake of tracking at the HTML/JS layer.
>>
>> There was a conscious decision, early on, that QUIC would not attempt to
>> provide the same features as Tor (or any other sort of privacy broker).
>> It is simply impossible for a protocol to do a better job at that without
>> centralizing everything by default, which would then be a far greater
>> danger
>> to users than individual origin sessions. Using QUIC to communicate with
>> a user-selected, private intermediary (like Tor) would be much better, I
>> think,
>> than trying to do the same with H1/TLS or H2/TLS. Or at least it will be
>> once
>> there is a large number of users using the same protocols.
>>
>> > (And having important discussions on a Microsoft platform not
>> > controlled by the IETF is a bad idea, anyway, but I digress.)
>>
>> The IETF does not have the resources to provide a comparable issue
>> tracking
>> system, let alone one that manages PRs and version control for authors,
>> while
>> providing extensive search capabilities at the same time. It's a tool.
>>
>> ....Roy
>>
>>