Subject: [Privacy-pass] Privacy Pass: Applications & Extensions

From: Alex Davidson <[email-masked]>
Date: Tue, 21 Jan 2020 12:36:43 +0000

Hi all,

One of the topics that we have yet to properly discuss is around the scale of applications (and associated extensions) that we are considering for the Privacy Pass protocol. I think it might be best to start this discussion on list, but we can potentially carry it onto a side-meeting if we need one.

Some of the applications that we currently have are:

	• Privacy Pass browser extension: https://github.com/privacypass/challenge-bypass-extension <https://github.com/privacypass/challenge-bypass-extension>  
	• Trust Token API: https://github.com/WICG/trust-token-api <https://github.com/WICG/trust-token-api>     
	• PrivateStorage API: https://medium.com/least-authority/the-path-from-s4-to-privatestorage-ae9d4a10b2ae <https://medium.com/least-authority/the-path-from-s4-to-privatestorage-ae9d4a10b2ae>  
	• Ad confirmations: https://github.com/brave/brave-browser/wiki/Security-and-privacy-model-for-ad-confirmations <https://github.com/brave/brave-browser/wiki/Security-and-privacy-model-for-ad-confirmations>  
	• Partially blind signatures: https://engineering.fb.com/security/partially-blind-signatures/ <https://engineering.fb.com/security/partially-blind-signatures/>  

Some of these applications will be covered by the protocol as described in the main documents that will be agreed in the charter (provisionally protocol, architecture, API), but some may need extensions to the actual protocol. Some of the extensions that are considered are:

	• Hidden bit (with/without batching)
	• Public verifiability
	• Additional limited public attributes/labels (associated data)
		• Token expiration
	• Other changes to DLEQ proof mechanism

With this in mind, there are some immediate (non-exhaustive) questions that I think need addressing:

	- Are there any other applications/extensions that should be considered?
	- How should the protocol extensions be put forward, as part of the protocol document (or the existing document draft-irtf-cfrg-voprf <https://datatracker.ietf.org/doc/draft-irtf-cfrg-voprf/> document)? Or as separate smaller documents that only concern the specific extension functionality?
	- Who would be willing to help scope out the necessary extensions and provide review, if need be?

Cheers,
Alex

---

From: Steven Valdez <[email-masked]>
Date: Tue, 21 Jan 2020 10:17:46 -0500

- Are there any other applications/extensions that should be considered?
Hopefully as part of the BoF process, we'll hear of other use cases in the
wider community that could take advantage of this sort of
protocol/construction.

- How should the protocol extensions be put forward, as part of the
protocol document (or the existing document draft-irtf-cfrg-voprf
<https://datatracker.ietf.org/doc/draft-irtf-cfrg-voprf/> document)? Or as
separate smaller documents that only concern the specific extension
functionality?
Somewhat related to the charter question, but assuming actual specs for
extensions of the core protocol are in-charter.

Generally having separate smaller drafts initially for specific extension
functionality seems reasonable, folding in particularly common extensions
into the core document (If a lot of use cases find being able to issue
distrust via the hidden bit or supporting token expiration to be core,
etc). We probably don't want to overburden the core document with a ton of
extensions, but if there are extensions that many use cases are going to
end up using, then having them in core documents will help make sure the
security/privacy considerations take them into account, instead of just
being security/privacy considerations for a vanilla version of Privacy Pass
that isn't actually used anywhere.

For the current extensions under consideration, the crypto parts that are
compatible with the VOPRF draft might be reasonable to have as changes to
the document itself or further extension docs within CFRG (hidden bit
crypto is a generalization of the VOPRF construction, the alternate DLEQ
proof mechanisms similarly). Other parts like public verifiability are
fairly distinct designs from VOPRF and would be better off in their own
documents. Public Attributes/Token Expiration can probably be handled as
extensions on the key management/commitment side so probably would be a
document in the Privacy Pass WG (or merged into the core architecture).

- Who would be willing to help scope out the necessary extensions and
provide review, if need be?
I'd be willing to help with scoping extensions and providing review, though
we'll probably want to have a path for getting consensus in the working
group on what extensions should be part of the core spec and potentially
adding other extensions in the future as we find issues/holes in the design
that could support other useful extensions.

On Tue, Jan 21, 2020 at 7:37 AM Alex Davidson <adavidson=
[email-masked]> wrote:

> Hi all,
>
> One of the topics that we have yet to properly discuss is around the scale
> of applications (and associated extensions) that we are considering for the
> Privacy Pass protocol. I think it might be best to start this discussion on
> list, but we can potentially carry it onto a side-meeting if we need one.
>
> • Privacy Pass browser extension:
> https://github.com/privacypass/challenge-bypass-extension
> • Trust Token API: https://github.com/WICG/trust-token-api
> • PrivateStorage API:
> https://medium.com/least-authority/the-path-from-s4-to-privatestorage-ae9d4a10b2ae
>
> • Ad confirmations:
> https://github.com/brave/brave-browser/wiki/Security-and-privacy-model-for-ad-confirmations
>
> • Partially blind signatures:
> https://engineering.fb.com/security/partially-blind-signatures/
>
> Some of these applications will be covered by the protocol as described in
> the main documents that will be agreed in the charter (provisionally
> protocol, architecture, API), but some may need extensions to the actual
> protocol. Some of the extensions that are considered are:
>
> - How should the protocol extensions be put forward, as part of the
> protocol document (or the existing document draft-irtf-cfrg-voprf
> <https://datatracker.ietf.org/doc/draft-irtf-cfrg-voprf/> document)? Or
> as separate smaller documents that only concern the specific extension
> functionality?
> --
> Privacy-pass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/privacy-pass
>

-- 

Steven Valdez |  Chrome Privacy Sandbox |  [email-masked] |
 210-692-4742

---

From: Michele Orrù <[email-masked]>
Date: Tue, 21 Jan 2020 10:27:52 -0500

> provide review, if need be?

Hi Alex,

I'd be really happy to help out with the reviews if needed !

---

From: Alex Davidson <[email-masked]>
Date: Wed, 22 Jan 2020 13:44:22 +0000

Hi Steven,

> On 21 Jan 2020, at 15:17, Steven Valdez <svaldez=[email-masked]> wrote:
> 
> Somewhat related to the charter question, but assuming actual specs for extensions of the core protocol are in-charter.
> 
> Generally having separate smaller drafts initially for specific extension functionality seems reasonable, folding in particularly common extensions into the core document (If a lot of use cases find being able to issue distrust via the hidden bit or supporting token expiration to be core, etc). We probably don't want to overburden the core document with a ton of extensions, but if there are extensions that many use cases are going to end up using, then having them in core documents will help make sure the security/privacy considerations take them into account, instead of just being security/privacy considerations for a vanilla version of Privacy Pass that isn't actually used anywhere.
> 
> For the current extensions under consideration, the crypto parts that are compatible with the VOPRF draft might be reasonable to have as changes to the document itself or further extension docs within CFRG (hidden bit crypto is a generalization of the VOPRF construction, the alternate DLEQ proof mechanisms similarly). Other parts like public verifiability are fairly distinct designs from VOPRF and would be better off in their own documents. Public Attributes/Token Expiration can probably be handled as extensions on the key management/commitment side so probably would be a document in the Privacy Pass WG (or merged into the core architecture)..

I also prefer the idea of having separate smaller documents for appropriately-scoped extensions, and I agree with your initial categorisation. In terms of the those that would be appropriate for the VOPRF draft, hopefully we may be able to include these in a draft that is released before IETF107.

> I'd be willing to help with scoping extensions and providing review, though we'll probably want to have a path for getting consensus in the working group on what extensions should be part of the core spec and potentially adding other extensions in the future as we find issues/holes in the design that could support other useful extensions.

Sure, this makes sense. We have the extensions that we’re currently considering, and for future extensions we can decide at the potential BoF session upon the structure of how extensions are put forward and are subsequently ratified by the WG.

Alex

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 22 Jan 2020 06:27:24 -0800

> I'd be really happy to help out with the reviews if needed !

+1 — I can help with the main work and reviews as needed.

Best,
Chris

---

From: Sofía Celi <[email-masked]>
Date: Thu, 23 Jan 2020 00:04:49 -0500

Hi, Alex!

Thanks for all of this!

> provide review, if need be?
I will like to help with review.

Thanks!

-- 
Sofía Celi
@claucece
Cryptographic research and implementation at many places
FAB9 3EDC 7CDD 1198 DCFD  4558 91BB 6B45 6F44 2D02

---

From: Mariana Raykova <[email-masked]>
Date: Thu, 23 Jan 2020 13:44:52 -0500

Hello,

If we want to start discussion of extensions of Privacy pass, we have a
proposal that extends the Privacy Pass functionality with a private
metadata bit. You can find our construction here
https://eprint.iacr.org/2020/072 and we are interested to hear feedback.

Mariana

---

From: Mariana Raykova <[email-masked]>
Date: Wed, 29 Jan 2020 16:20:58 -0500

Hi Alex,

We thought about this with Tancrede Lepoint and we also discussed it with
Hugo Krawczyk. Our construction is actually not a VOPRF, the evaluation is
a randomized functionality and this is critical for the security properties
of the token construction we are proposing. In fact using directly a VOPRF,
which by definition has deterministic evaluation, cannot be sufficient for
the security properties we need to achieve for the private metadata. Our
construction achieves security properties needed for Privacy Pass type of
functionality and its extensions (e.g. unforgeability, unlinkability,
private metadata bit etc.) but not VOPRF. Note that trust token
constructions such as Privacy Pass do not imply the need for VOPRF (in fact
the security requirements of our extension rule out the use of
deterministic PRF). Trying to phrase our construction as some new sort of a
randomized PRF would require a whole new set of security properties (and
proofs) and we do not think it will be very instructive or useful. It seems
to us that our construction belongs much better in a write-up that focuses
one level up at the security properties of a Privacy Pass type of primitive
rather than VOPRF.

Mariana

On Mon, Jan 27, 2020 at 1:33 PM Alex Davidson <adavidson=
[email-masked]> wrote:

> Hi Mariana,
>
> Thanks for linking to this. I have yet to go over the security proof in
> detail but this is something I hope to do in the near future.
> I think that this extension definitely fits into draft-irtf-cfrg-voprf (as
> Steven mentioned previously) as it provides a new proof mechanism at the
> VOPRF-level.
>
> Since the protocol changes to accommodate the new proof system, the best
> way to include this extension in the draft could be as a new protocol mode
> with different security guarantees? In terms of how it could be specified,
> it seems that the protocol description in Section 6 has broadly the same
> structure as the original protocol. So it may be possible to just give new
> specifications for each of the API functions (see
> https://tools.ietf.org/html/draft-irtf-cfrg-voprf-02#section-4.6)?
> As the construction & proof are now on eprint, we can to link to this
> directly from the draft for the security justification.
>
> If you would be interested in making a PR to the repository here
> https://github.com/cfrg/draft-irtf-cfrg-voprf/ with the construction
> details, then that would be great.
>
> Best,
> Alex
>
> On 23 Jan 2020, at 18:44, Mariana Raykova <
> marianar=[email-masked]> wrote:
>
> Hello,
>

---

From: Nick Sullivan <[email-masked]>
Date: Wed, 29 Jan 2020 14:24:02 -0800

Hi Mariana,

Given this is the case, it may be worth bringing this new construction (or
some generalization thereof) to the CFRG for review. Having an
informational RFC about a mechanism that has undergone RG approval is
something that is strongly recommended for IETF protocols. That's part of
the reason we brought the (V)OPRF draft to CFRG a while back.

We'd likely be willing to help with this effort if you're interested.

Best,
Nick

On Wed, Jan 29, 2020 at 1:21 PM Mariana Raykova <marianar=
[email-masked]> wrote:

>> I think that this extension definitely fits into draft-irtf-cfrg-voprf
>> (as Steven mentioned previously) as it provides a new proof mechanism at
>> the VOPRF-level.
>>
>> structure as the original protocol.. So it may be possible to just give new