Re: [Cfrg] Call for participation: privacy-pass virtual IETF BoF

Alex Davidson <alex.davidson92@gmail.com> Wed, 25 March 2020 10:50 UTC

Return-Path: <alex.davidson92@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546163A0D14 for <cfrg@ietfa.amsl.com>; Wed, 25 Mar 2020 03:50:50 -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, 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 vRlXettF-ogo for <cfrg@ietfa.amsl.com>; Wed, 25 Mar 2020 03:50:48 -0700 (PDT)
Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 2549F3A0D20 for <cfrg@irtf.org>; Wed, 25 Mar 2020 03:50:47 -0700 (PDT)
Received: by mail-ua1-x92f.google.com with SMTP id f9so548039uaq.8 for <cfrg@irtf.org>; Wed, 25 Mar 2020 03:50:47 -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=i4zUrcM0F0BVmcqR4USyGzrQLshZjDe8q/YLcr5okXg=; b=jaFEZDVhXo1XpiqQGZBnRoCJOsnWIC6184UnVgFlhXOQe7uOWkIl+QQWo+FQ3i4BMJ rRd7mb6LFyBwM1uHoLceUpgXwgn9UhiLN/UaxuhQq03uYN6E6m2cHDWiHwAoKVZzCUwT cpjRrvV5xmqHpq9JM7iKQ7NPnWIRJ4GLgS/hXIF3NFAiikqwgvA6bTDzZ07QE2sxrbIU qB0awpm2Lhq/1GPx1tiXc3Mk1peKzJQ73pNEnOeeFCS0T7I29h5rBnbT/zyXv303wsEk Ms+GOI2VzZpnfxM3ryCPCxrdZhdTHDs0lbrJHQVZRY60Ga+EWp0Apdbsu2img1/oPfN7 tA7Q==
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=i4zUrcM0F0BVmcqR4USyGzrQLshZjDe8q/YLcr5okXg=; b=eF2t2qDaaXp+Z2jr5xGylBxE33YGxlWw6gX/ex59nd1nUHyWKo4pq1TLQ5yp9lmRW+ cnTbf3fBuNOqpR3p+7+v1cuR/faWwnRfQJKXPxi3Q+krOweH9tF5fsf6xPuVXFJZmaWg q1AL2M04Ckc8WwEn9z+3i9NXjZjvO4T9W/fAIMKr6BCJHoq9svU/1/4TU+k5oDVnmx/Q +kle7UqyxepEYUfBw7xW4EAny1Wm0jcuLy4/+rJduSO09z9vAQMJXHBXJzBwc44OhF0o KWCOESiOIZSp/khkSyAsiMhlalugCM2t8yZ4R25KvBd5yFJ1A0IOmY9UgwnAbNk7IcEG bKDA==
X-Gm-Message-State: ANhLgQ1yPX/wxvvcL4BBA69prGek60e0LBLphuiOlMl21h+Mqo2qWtw0 P7d/PcrHJw2HDS1SkIilY2p4C/XB1XmXF/7QBg==
X-Google-Smtp-Source: ADFU+vvQvTZBp68DnnPeFMwW3dnjUKzXsbphHwyRQK3DWM4M4+qg5GVFvNagG1kK36PLdpcAs9fAaS5Jy7PQ6WvXGGI=
X-Received: by 2002:ab0:424:: with SMTP id 33mr1886285uav.143.1585133446860; Wed, 25 Mar 2020 03:50:46 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5V+fOND7wqzFBjP4ZG30zBvFTd5vaDp-fQwpKCqRT68-t_Wg@mail.gmail.com> <AM0PR08MB371698AC1A74C0514E6674FFFACE0@AM0PR08MB3716.eurprd08.prod.outlook.com>
In-Reply-To: <AM0PR08MB371698AC1A74C0514E6674FFFACE0@AM0PR08MB3716.eurprd08.prod.outlook.com>
From: Alex Davidson <alex.davidson92@gmail.com>
Date: Wed, 25 Mar 2020 10:50:36 +0000
Message-ID: <CAD5V+fM=vsaRtxExmqh5ctOuMF2kA58Zp01p2hKC6JhJ_gtrGw@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="00000000000005940805a1aba454"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/0VZXSOcUIFRpmpx8-78YY7gXjdo>
Subject: Re: [Cfrg] Call for participation: privacy-pass virtual IETF BoF
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Mar 2020 10:50:51 -0000

Hi Hannes,

On Wed, Mar 25, 2020 at 7:41 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com>
wrote:

> Hi Alex,
>
>
>
> Do you have a problem statement document/write-up somewhere as well?
>

We don't have an explicit problem statement write-up, but we cover this
in the introduction of the protocol draft (
https://tools.ietf.org/html/draft-davidson-pp-protocol-00).
I'll try and have this covered more broadly on the website.


> I would like to get to understand whether this is something I should pay
> attention to. Why is there a problem? What is the prior work and why is it
> insufficient to solve the problem?
>

We're particularly targeting the case of providing privacy-preserving
propagation of trust attestation across the Internet. This is something
that is important for platforms that need to check whether clients are
non-fraudulent actors before processing their requests. The platforms
may want to provide some sort of credential/token to the client so that
the client does not have to re-prove their honesty each time they
interact with the server. Typically, this sort of thing can be done with
cookies. However, if the platform acts as a gatekeeper for multiple
disparate services (such as a CDN or ad-space platform), then this
approach fails to provide utility to clients that try to access multiple
services. The alternative (challenging every request) is impractical for
clients, and also infeasible in cases

Privacy Pass solves this problem by providing clients with tokens that
can be used for multiple disparate transactions. The tokens themselves
are both unforgeable and unlinkable from each other, and the transaction
in which they were issued.


> Who needs to be involved to make this successful? What are the incentives
> (or disincentives) of the parties in the ecosystem?
>

In term of applications, the Cloudflare CDN allows clients (with an
open-source browser extension installed [1]) to redeem tokens to bypass
challenges that are used to protect Cloudflare websites. There is also
an API being developed to embed the Privacy Pass exchange directly into
browsers, that Chromium intends to implement [2]. There are also some
other use-cases for variants of the Privacy Pass protocol as an
anonymous mechanism for receiving currency in the Brave browser [3], and
for providing anonymous receipts for proof-of-purchase [4,5].

Given that there are a number of applications already, the
standardisation effort is focused on establishing a protocol that fits
with each of the different use-cases. It is also concerned with the
discussion of the ecosystem at large, and how multiple service providers
that support Privacy Pass operate within the same environment. Each
ecosystem itself demands a strict analysis as it determines the privacy
budget of the clients within it. The ecosystem should also be robust to
attempts from malicious servers to try and subvert client privacy. This
discussion is covered in more detail in the architecture document [6].

Finally, in terms of making this a success, we're looking for as many
parties as possible who would be interested in implementing/developing
the standard to be involved. We have support from the vendors that I
have listed above (amongst others) but we're still in the process of
developing all the possible use-cases for the protocol. In particular, the
protocol is currently targeted at the Internet setting, but there may also
be
applications to other frameworks. So if there is anything here that you
think
may be interesting, then it would be really useful to have your input.

Happy to answer more questions should anything remain unclear.

Best,
Alex

[1]: https://github.com/privacypass/challenge-bypass-extension/
[2]: https://github.com/WICG/trust-token-api
[3]:
https://github.com/brave/brave-browser/wiki/Security-and-privacy-model-for-ad-confirmations
[4]:
https://medium.com/least-authority/the-path-from-s4-to-privatestorage-ae9d4a10b2ae
[5]: https://openprivacy.ca/assets/towards-anonymous-prepaid-services.pdf
[6]: https://tools.ietf.org/html/draft-davidson-pp-architecture-00

>