Re: [Privacy-pass] Updated WG charter text

[Christopher Wood <[e-mail]>]

On Wed, Apr 22, 2020, at 5:32 PM, Martin Thomson wrote:
> A few inline comments, before I think about this some more...
> 
> On Wed, Apr 22, 2020, at 01:00, Alex Davidson wrote:
> > 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
> 
> 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. 

> > 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
> 
> 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. 

> > 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.
> 
> 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.
> 
> > 4. Describing verification mechanisms for sanctioning or trusting
> >  Issuers and their corresponding keying material.
> 
> Sanctioning implies punishment, which we can't write a protocol for.

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.
> 
> > 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
> >  maliciously.
> 
> 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?

> > 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.

Best,
Chris