Subject: [Privacy-pass] Updated WG charter text

From: Alex Davidson <[email-masked]>
Date: Tue, 21 Apr 2020 16:00:36 +0100

Hi all,

I took the opportunity to write up a new candidate WG charter following the feedback that we have received so far. I’ve submitted the new charter text as a GitHub PR here: https://github.com/alxdavids/privacy-pass-ietf/pull/12 <https://github.com/alxdavids/privacy-pass-ietf/pull/12>. If anyone has any comments/feedback on this version please feel free to add them to the PR. I’ve also pasted the new text below in case anyone wants to raise any points on the mailing list directly.

Cheers,
Alex

p.s. I’m currently working in a personal GitHub repo but I could move everything to a separate privacypass-specific working space, if that would be preferable?

Charter text
=========

The Privacy Pass protocol provides a performant, application-layer
mechanism for anonymous token creation and redemption. Servers (Issuers)
create and later verify tokens that are redeemed by an ecosystem of
clients, such that:

- Any token granted by a given Issuer is unlinkable with all other
  tokens granted by the same Issuer.
- Clients can verify that a token granted by an Issuer corresponds to a
  committed keypair.
- Tokens are unforgeable.
- The token issuance and redemption mechanisms are efficient.

The primary purpose of the Privacy Pass Working Group is to develop and
standardize a protocol that meets these requirements, influenced by
applications that have arisen from the wider community. The aims of the
Working Group can be split into three distinct goals:

First, specify an extensible protocol for creating and redeeming
anonymous and transferrable tokens. The protocol should permit suitable
cryptographic ciphersuites and security parameterization for
cryptographic agility. Negotiation of cryptographic parameters is an
application-specific property and thus out of scope for the Working
Group. Specification of the underlying cryptographic algorithms or
protocols is also out of scope. The Working Group will specify a
preliminary set of extensions, including Issuer-supplied metadata and
public verifiability, as well as any additional extensions that may
arise in the future. Security and privacy properties of the protocol
shall be well-documented.

Second, describe and develop protocol use cases and properties thereof.
This includes, though is not limited to:

1. Describing use cases and interfaces that allow the protocol to be
   used for those use cases.
2. Defining the privacy goals for each Client during protocol execution,
   along with expectations placed on the Issuers and the ecosystem at
   large.
3. Describing parameterizations that control the Client privacy budget
   and Issuer security parameters.
4. Describing verification mechanisms for sanctioning or trusting
   Issuers and their corresponding keying material.
5. Describing where key material is stored and how it is accessed.
6. Specifying mechanisms for ensuring that Issuers are not acting
   maliciously.
7. Describing the procedure for including small amounts of metadata with
   Issued tokens, as well as the associated impacts on privacy.
8. Describing the risk and possible ramifications of Issuer
   centralization, and exploring possible mechanisms to mitigate these
   risks.

Third, and finally, specify a HTTP-layer API for the protocol. This
includes a common understanding of how Privacy Pass is integrated with
HTTP requests and responses for web-based applications.

Note that the specifications developed by this working group will be
informed by the following initial drafts:

- draft-davidson-pp-protocol-00;
- draft-davidson-pp-architecture-00;
- draft-svaldez-pp-http-api-00.

These existing drafts may be further developed into the core
deliverables of the working group, supplemented by any additional
extensions. Alternatively, they may contribute indirectly to a future
set of documents that meet the core goals of the working group.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 21 Apr 2020 20:49:12 -0400

I like this text.  Thanks for the update!

On Tue, Apr 21, 2020 at 11:12 AM Alex Davidson <adavidson=
[email-masked]> wrote:

> Hi all,
>
> I took the opportunity to write up a new candidate WG charter following
> the feedback that we have received so far. I’ve submitted the new charter
> text as a GitHub PR here:
> https://github.com/alxdavids/privacy-pass-ietf/pull/12. If anyone has any
> comments/feedback on this version please feel free to add them to the PR.
> I’ve also pasted the new text below in case anyone wants to raise any
> points on the mailing list directly.
>
> Cheers,
> Alex
>
> p.s. I’m currently working in a personal GitHub repo but I could move
> everything to a separate privacypass-specific working space, if that would
> be preferable?
>
> Charter text
> =========
>
> --
> Privacy-pass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/privacy-pass
>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 23 Apr 2020 10:32:18 +1000

A few inline comments, before I think about this some more...

> Group. Specification of the underlying cryptographic algorithms or

This bit about choosing parameters seems to be in tension with the previous sentence.  One of the problems with a system like this is coordinating algorithm changes.  I think that we need a plan, not a big punt.

> public verifiability, as well as any additional extensions that may

What does "public verifiability" mean here?

>  and Issuer security parameters.

What is a "privacy budget"?  To be clear, I think that I know, and my opinion is that it is not a good framing for this.  I also think that it is not a good reference model to use in general.

>  Issuers and their corresponding keying material.

Sanctioning implies punishment, which we can't write a protocol for.

If this is about providing technical safeguards against the potential for issuers to abuse key management for a covert channel, then say that.

> 5. Describing where key material is stored and how it is accessed.

I don't think that we need this in a charter.

> 6. Specifying mechanisms for ensuring that Issuers are not acting

This seems a bit open-ended.  Will this extend to audits of their processes?  I don't think we have a protocol for that either.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 22 Apr 2020 18:46:50 -0700

> Sanctioning implies punishment, which we can't write a protocol for.

I'm pretty sure this was intended in the "give official permission or
approval for" sense, not the "impose a santction on" sense ... but the
ambiguity is not worth keeping around; we should reword.

-Ben

---

From: "Christopher Wood" <[email-masked]>
Date: Thu, 23 Apr 2020 09:52:15 -0700

On Wed, Apr 22, 2020, at 5:32 PM, Martin Thomson wrote:
> This bit about choosing parameters seems to be in tension with the 
> previous sentence.  One of the problems with a system like this is 
> coordinating algorithm changes.  I think that we need a plan, not a big 
> punt.

I'm thinking about this more like the DoH effort, which focused first and foremost on the protocol itself and punted other concerns such as discovery and whatnot. 

> What does "public verifiability" mean here?

I think it means that someone beyond the party which issued the token (and holds the OPRF private key) can verify the authenticity of a token. As an example, blind signatures have this property. 

> What is a "privacy budget"?  To be clear, I think that I know, and my 
> opinion is that it is not a good framing for this.  I also think that 
> it is not a good reference model to use in general.
> 

That's a good point. Maybe we should just say, "Describing verification mechanisms for trusting Issuers and their corresponding keying material"?

> If this is about providing technical safeguards against the potential 
> for issuers to abuse key management for a covert channel, then say that.
> 
> This seems a bit open-ended.  Will this extend to audits of their 
> processes?  I don't think we have a protocol for that either.

Maybe we could refine this by specifying particular attacks we're concerned about, such as key tagging?

> >  centralization, and exploring possible mechanisms to mitigate these

Best,
Chris

---

From: Alex Davidson <[email-masked]>
Date: Tue, 28 Apr 2020 11:47:33 +0100

Thanks all for the feedback! I’ve pushed updated wording to the GitHub PR (https://github.com/alxdavids/privacy-pass-ietf/pull/12/commits/e987d2ba60fa7b0ba986a65c29214ce893d7b667) and also added it at the bottom of this email. I’ve inlined some responses to the specific points explaining the changes below.

> On 23 Apr 2020, at 17:52, Christopher Wood <[email-masked]> wrote:
> 

Due to the restrictions on key material updates for client privacy, the ciphersuite is determined explicitly by the key that the server is currently using. Moreover, the supported ciphersuites should be specified by the underlying cryptographic protocol that is being used. Therefore, I think the choice of ciphersuite is a unilateral decision made by the server, and so the negotiation framework does not really belong to the protocol description.

> I think it means that someone beyond the party which issued the token (and holds the OPRF private key) can verify the authenticity of a token. As an example, blind signatures have this property. 

Yes, this is what we were alluding to. I’ve updated the wording to be more explicit on this.

>> it is not a good reference model to use in general.

This makes sense, I’ve changed the wording to directly refer to the size of the client’s anonymity set, which is what we were implicitly referring to here and is also used elsewhere in the charter.

> That's a good point. Maybe we should just say, "Describing verification mechanisms for trusting Issuers and their corresponding keying material”?

Agree, incorporated this wording.

>> I don't think that we need this in a charter.

Removed this point.

> Maybe we could refine this by specifying particular attacks we're concerned about, such as key tagging?

I removed this point as I think it is now covered by what is written in point 4. However, I mentioned specifically the attack surface that is being considered with the verification mechanisms that we will specify.

Thanks,
Alex

Updated Charter text
================

First, specify an extensible protocol for creating and redeeming
anonymous and transferrable tokens. The protocol should permit suitable
cryptographic ciphersuites and security parameterization for
cryptographic agility. Negotiation of cryptographic parameters during
the protocol is an application-specific property and thus out of scope
for the Working Group. Specification of the underlying cryptographic
algorithms or protocols is also out of scope. The Working Group will
specify a preliminary set of extensions, including Issuer-supplied
metadata and alternative cryptographic instantiations that support
public verifiability of Issued tokens, as well as any additional
extensions that may arise in the future. Security and privacy properties
of the protocol shall be well-documented.

1. Describing use cases and interfaces that allow the protocol to be
   used for those use cases.
2. Defining the privacy goals for each Client during protocol execution,
   along with expectations placed on the Issuers and the ecosystem at
   large.
3. Describing recommended parameterizations of variables associated with
   the protocol ecosystem that control the size of the anonymity set
   that the client belongs to.
4. Describing verification mechanisms for trusting Issuers and their
   corresponding keying material. Such mechanisms should prevent Issuers
   from presenting any key material that could be used to deanonymize
   clients.
5. Describing the procedure for including small amounts of metadata with
   Issued tokens, as well as the associated impacts on privacy.
6. Describing the risk and possible ramifications of Issuer
   centralization, and exploring possible mechanisms to mitigate these
   risks.