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

From: Alex Davidson <[email-masked]>
Date: Thu, 19 Mar 2020 10:40:48 +0000

Dear CFRG,

I just wanted to draw your attention to the privacy-pass
<https://datatracker.ietf.org/group/privacypass/meetings/> virtual IETF
Birds of a Feather (BoF) session being held next week on *Thursday 26 March
(20:00-22:00 UTC)* that may be of interest to members of this community.

The BoF will be held entirely remotely and aims to decide whether a WG
should be formed for standardising the Privacy Pass protocol (
https://privacypass.github.io). The protocol provides clients with the
ability to redeem blinded tokens that prove ownership of some attribute to
a server, without revealing anything else about the client's identity. It
is based heavily on protocols for computing verifiable oblivious
pseudorandom functions (VOPRFs). Constructions of VOPRF protocols have
already been proposed in an ongoing CFRG draft (
https://tools.ietf.org/html/draft-irtf-cfrg-voprf-03). There are many
applications that already make use of some form of the Privacy Pass
protocol for achieving privacy-preserving authorisation in the Internet
setting [7-11].

The full agenda for the BoF is already available [5]. In the meeting, we
will be discussing three initial drafts that describe the protocol [1],
architecture [2] and intended web API [3], along with aiming to finalise
the WG charter that we currently have [4]. Anyone is very welcome to join
the meeting and the mailing list [6] to discuss the direction of the
standardisation and the proposed charter. Any feedback from the community
would be highly appreciated! More information about how to join the meeting
remotely will be posted to the privacy-pass mailing list in due course.

Looking forward to hearing from you!

Best,
Alex

[1] https://tools.ietf.org/html/draft-davidson-pp-protocol-00
[2] https://tools.ietf.org/html/draft-davidson-pp-architecture-00
[3] https://tools.ietf.org/html/draft-svaldez-pp-http-api-00
[4] https://github.com/alxdavids/privacy-pass-ietf/blob/master/CHARTER.md
[5]
https://datatracker.ietf.org/meeting/107/materials/agenda-107-privacypass
[6] https://www.ietf.org/mailman/listinfo/privacy-pass
[7]
https://blog.cloudflare.com/supporting-the-latest-version-of-the-privacy-pass-protocol/
[8]
https://blog.chromium.org/2019/08/potential-uses-for-privacy-sandbox.html
[9] https://github.com/WICG/trust-token-api
[10]
https://medium.com/least-authority/the-path-from-s4-to-privatestorage-ae9d4a10b2ae
[11] https://engineering.fb.com/security/partially-blind-signatures/

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 25 Mar 2020 07:41:17 +0000

Hi Alex,

Do you have a problem statement document/write-up somewhere as well?

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? Who needs to be involved to make this successful? What are the incentives (or disincentives) of the parties in the ecosystem?

Ciao
Hannes

From: Cfrg <[email-masked]> On Behalf Of Alex Davidson
Sent: Thursday, March 19, 2020 11:41 AM
To: [email-masked]
Subject: [Cfrg] Call for participation: privacy-pass virtual IETF BoF

Dear CFRG,

I just wanted to draw your attention to the privacy-pass<https://datatracker.ietf.org/group/privacypass/meetings/> virtual IETF Birds of a Feather (BoF) session being held next week on Thursday 26 March (20:00-22:00 UTC) that may be of interest to members of this community.

The BoF will be held entirely remotely and aims to decide whether a WG should be formed for standardising the Privacy Pass protocol (https://privacypass.github.io<https://privacypass.github.io/>). The protocol provides clients with the ability to redeem blinded tokens that prove ownership of some attribute to a server, without revealing anything else about the client's identity. It is based heavily on protocols for computing verifiable oblivious pseudorandom functions (VOPRFs). Constructions of VOPRF protocols have already been proposed in an ongoing CFRG draft (https://tools.ietf.org/html/draft-irtf-cfrg-voprf-03). There are many applications that already make use of some form of the Privacy Pass protocol for achieving privacy-preserving authorisation in the Internet setting [7-11].

The full agenda for the BoF is already available [5]. In the meeting, we will be discussing three initial drafts that describe the protocol [1], architecture [2] and intended web API [3], along with aiming to finalise the WG charter that we currently have [4]. Anyone is very welcome to join the meeting and the mailing list [6] to discuss the direction of the standardisation and the proposed charter. Any feedback from the community would be highly appreciated! More information about how to join the meeting remotely will be posted to the privacy-pass mailing list in due course.

Best,
Alex

[1] https://tools.ietf.org/html/draft-davidson-pp-protocol-00
[2] https://tools.ietf.org/html/draft-davidson-pp-architecture-00
[3] https://tools.ietf.org/html/draft-svaldez-pp-http-api-00
[4] https://github.com/alxdavids/privacy-pass-ietf/blob/master/CHARTER.md
[5] https://datatracker.ietf.org/meeting/107/materials/agenda-107-privacypass
[6] https://www.ietf.org/mailman/listinfo/privacy-pass
[7] https://blog.cloudflare.com/supporting-the-latest-version-of-the-privacy-pass-protocol/
[8] https://blog.chromium.org/2019/08/potential-uses-for-privacy-sandbox.html
[9] https://github.com/WICG/trust-token-api
[10] https://medium.com/least-authority/the-path-from-s4-to-privatestorage-ae9d4a10b2ae
[11] https://engineering..fb.com/security/partially-blind-signatures/<https://engineering.fb.com/security/partially-blind-signatures/>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Alex Davidson <[email-masked]>
Date: Wed, 25 Mar 2020 10:50:36 +0000

Hi Hannes,

> 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

---

From: Jeff Burdges <[email-masked]>
Date: Wed, 25 Mar 2020 12:14:53 +0100

I’ve wondered if there should  be a general DLEQ proof draft that abstracts both the VRF proposal and the privacy pass proposal?

It’s hard for me to imagine anyone implementing either proposal without producing that abstract DLEQ proof machinery, if only for their own peace of mind.  At the same time, these DLEQ proofs are not miss-use resistant like signatures, which includes VRFs, or perhaps like PrivacyPass.

I suppose miss-use resistance wins here, but I have thought only about miss-use resistance for VRFs, not for PrivacyPass.  At least some tricks remain the same, like issuing public keys must be included with the nonce when hashed-to-the-curve to prevent related key attacks.

Jeff