Subject: Re: [Privacy-pass] Updated WG charter text

From: Alex Davidson <[email-masked]>
Date: Wed, 6 May 2020 10:39:51 +0100

It has been mentioned off-list that the charter would benefit from having explicit milestones laid out in the document. To this end, here are the key tasks that need to be completed by the WG (in my opinion):

- Specification of protocol & protocol architecture.
- Specification of HTTP API (in coordination with W3C).
- Formal analysis of protocol.
- Concrete implementations.
- Any protocol extensions.

I think getting the first two milestones done for the core instantiation of the protocol (currently documented) will be important in facilitating the three steps afterwards. The final three steps can be done in parallel, since they do not depend on each other. In terms of a rough timeline, I would expect that achieving the first step would be doable by Spring 2021, and then the HTTP API could follow in mid-2021. The rest of the steps are slightly variable, but I would expect that the rest of the work could completed in a further 6-12 months.

Questions: Do these milestones reflect the scope of required work to everyone else? Does the proposed timeline make sense?

Next steps: Once we have agreement (/if no-one disagrees with what is written), then I’ll add it to the charter. We will then take this version of the charter forward in the WG formation process.

> On 28 Apr 2020, at 11:47, Alex Davidson <[email-masked]> wrote:
> 
> 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 <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:
>> 
>> On Wed, Apr 22, 2020, at 5:32 PM, Martin Thomson wrote:
>>>> 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. 
> 
> 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.
> 
>>>> 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. 
> 
> Yes, this is what we were alluding to. I’ve updated the wording to be more explicit on this.
> 
>> 
>>>> 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.
> 
> 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.
> 
>>>> 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”?
> 
> Agree, incorporated this wording.
> 
>>> 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.
> 
> Removed this point.
> 
>>>> 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?
> 
> 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
> ================
> 
> 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 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.
> 
> 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 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.
> 
> 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: Steven Valdez <[email-masked]>
Date: Wed, 6 May 2020 10:05:44 -0400

One distinction possibly worth making for milestones is that there are two
sorts of HTTP-level APIs.

There's the wrapping for communication between client and issuers, the
headers/endpoints/HTTP requests/responses made as part of issuance and
redemption requests, as well as the key management story/recommendations
for how to distribute key materials and configuration information.

Then there's the API that HTTP consumers/websites/etc would be using to
call into the protocol, the JS/HTML attributes that you might need to hook
into PrivacyPass, allow a website to include tokens or request tokens.

I think the first is probably more important initially to provide some sort
of API that can be used for implementations of the protocol. But also
shouldn't require much (if any) W3C coordination.

The second one is more important for building use cases on top of and
seeing what interfaces to expose to developers/consumers and will likely be
the HTTP-level API that will need more coordination with the W3C
specs/Fetch/etc.

On Wed, May 6, 2020 at 5:40 AM Alex Davidson <adavidson=
[email-masked]> wrote:

> It has been mentioned off-list that the charter would benefit from having
> explicit milestones laid out in the document. To this end, here are the key
> tasks that need to be completed by the WG (in my opinion):
>
> I think getting the first two milestones done for the core instantiation
> of the protocol (currently documented) will be important in facilitating
> the three steps afterwards. The final three steps can be done in parallel,
> since they do not depend on each other. In terms of a rough timeline, I
> would expect that achieving the first step would be doable by Spring 2021,
> and then the HTTP API could follow in mid-2021. The rest of the steps are
> slightly variable, but I would expect that the rest of the work could
> completed in a further 6-12 months.
>
> Questions: Do these milestones reflect the scope of required work to
> everyone else? Does the proposed timeline make sense?
>
> Next steps: Once we have agreement (/if no-one disagrees with what is
> written), then I’ll add it to the charter. We will then take this version
> of the charter forward in the WG formation process.
>
> 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.
>
> 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.
>
>
> 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.
>
>
> 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”?
>
>
> 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
> ================
>
> --
> 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: Alex Davidson <[email-masked]>
Date: Fri, 8 May 2020 11:12:52 +0100

Yeah, this is a good point. So we could potentially rewrite the milestones as:

- Specification of protocol & surrounding architecture.
- Specification of application-layer requirements (including HTTP integration).
- Specification of HTTP browser API (in coordination with W3C).
- Formal analysis of protocol.
- Concrete implementations.
- Any protocol extensions.

I think we may be able to stick to the same timeline? Because the W3C coordination on the browser API can happen whilst the remaining milestones are completed, and after the application-layer requirements have been specced out.

> On 6 May 2020, at 15:05, Steven Valdez <svaldez=[email-masked]> wrote:
> 
> One distinction possibly worth making for milestones is that there are two sorts of HTTP-level APIs.
> 
> There's the wrapping for communication between client and issuers, the headers/endpoints/HTTP requests/responses made as part of issuance and redemption requests, as well as the key management story/recommendations for how to distribute key materials and configuration information.
> 
> Then there's the API that HTTP consumers/websites/etc would be using to call into the protocol, the JS/HTML attributes that you might need to hook into PrivacyPass, allow a website to include tokens or request tokens.
> 
> I think the first is probably more important initially to provide some sort of API that can be used for implementations of the protocol. But also shouldn't require much (if any) W3C coordination.
> 
> The second one is more important for building use cases on top of and seeing what interfaces to expose to developers/consumers and will likely be the HTTP-level API that will need more coordination with the W3C specs/Fetch/etc.  
> 
> On Wed, May 6, 2020 at 5:40 AM Alex Davidson <adavidson=[email-masked] <mailto:[email-masked]>> wrote:
> I think getting the first two milestones done for the core instantiation of the protocol (currently documented) will be important in facilitating the three steps afterwards.. The final three steps can be done in parallel, since they do not depend on each other. In terms of a rough timeline, I would expect that achieving the first step would be doable by Spring 2021, and then the HTTP API could follow in mid-2021. The rest of the steps are slightly variable, but I would expect that the rest of the work could completed in a further 6-12 months.
> 
>> On 28 Apr 2020, at 11:47, Alex Davidson <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On 23 Apr 2020, at 17:52, Christopher Wood <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 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. 
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/privacy-pass <https://www.ietf.org/mailman/listinfo/privacy-pass>
> 
> 
> -- 
> 
> Steven Valdez |	 Chrome Privacy Sandbox |	 [email-masked] <mailto:[email-masked]> |	 210-692-4742

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 08 May 2020 08:00:44 -0700

On Fri, May 8, 2020, at 3:12 AM, Alex Davidson wrote:
> I think we may be able to stick to the same timeline? Because the W3C 
> coordination on the browser API can happen whilst the remaining 
> milestones are completed, and after the application-layer requirements 
> have been specced out.

These look good to me! I agree that this lines up with the timeline you proposed earlier, which seems quite reasonable. 

One small nit: I might fold formal analysis and implementation efforts into the first milestone, as I'd expect them to happen in tandem.

Best,
Chris

> > On Wed, May 6, 2020 at 5:40 AM Alex Davidson <adavidson=[email-masked]> wrote:
> >>> 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.
> >>> 
> > Steven Valdez | Chrome Privacy Sandbox | [email-masked] | 210-692-4742
> 
> --

---

From: Joseph Salowey <[email-masked]>
Date: Fri, 8 May 2020 09:01:38 -0700

On Fri, May 8, 2020 at 8:01 AM Christopher Wood <[email-masked]> wrote:

> These look good to me! I agree that this lines up with the timeline you
> proposed earlier, which seems quite reasonable.
>
> One small nit: I might fold formal analysis and implementation efforts
> into the first milestone, as I'd expect them to happen in tandem.
>
>
[Joe] Agreed, the working group milestones mostly reflect document
deliverables.  Implementation and analysis are important.  Including a
statement about formal analysis in the text of the charter might be good,
maybe something like the following at then end of the fourth charter
paragraph:

"Formal analysis of the protocol will make sure the security and privacy
properties of the protocol
are well-understood and well-documented."

I think we might also need some estimates on target dates for milestones.
Below are some guesses.  Do you think it is reasonable to complete the
protocol and formal analysis in this time? Does the W3C have any milestones
in this area?

- Specification of protocol & surrounding architecture  - February 2021
- Specification of application-layer requirements (including HTTP
integration) - March 20201
- Specification of HTTP browser API (in coordination with W3C) - April 20201

> > > Then there's the API that HTTP consumers/websites/etc would be using
> to call into the protocol, the JS/HTML attributes that you might need to
> hook into PrivacyPass, allow a website to include tokens or request tokens.
> > >
> > > I think the first is probably more important initially to provide some
> sort of API that can be used for implementations of the protocol. But also
> > >> It has been mentioned off-list that the charter would benefit from
> having explicit milestones laid out in the document. To this end, here are
> the key tasks that need to be completed by the WG (in my opinion):
> > >>
> > >> I think getting the first two milestones done for the core
> instantiation of the protocol (currently documented) will be important in
> facilitating the three steps afterwards.. The final three steps can be done
> in parallel, since they do not depend on each other. In terms of a rough
> timeline, I would expect that achieving the first step would be doable by
> Spring 2021, and then the HTTP API could follow in mid-2021. The rest of
> the steps are slightly variable, but I would expect that the rest of the
> work could completed in a further 6-12 months.
> > >>
> > >>>> 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.
> > >>>
> > >>> Due to the restrictions on key material updates for client privacy,
> the ciphersuite is determined explicitly by the key that the server is
> > >>>> 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.
> > >>>
> > >>> 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”?
> > >>>
> > >>> 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
> > >>> ================
> > >>>

---

From: Alex Davidson <[email-masked]>
Date: Mon, 11 May 2020 14:13:52 +0100

Hi Joe,

Thanks for your points. I’ve added the statement on formal analysis to the working charter draft. I’ve added the following to the charter:

```
The following milestones (along with the approximate dates of
completion) will be used to judge the progress of the working group:

- Specification of protocol & surrounding architecture - February 2021.
- Specification of application-layer requirements (including HTTP integration) - June 2021.
- Specification of HTTP browser API (in coordination with W3C) - October 2021.
```

I decided to elongate the gaps between each of the deadlines to give more time for discussion on the subsequent work. I’ve attached the full charter text again below (and updated the PR here: https://github.com/alxdavids/privacy-pass-ietf/pull/12 <https://github.com/alxdavids/privacy-pass-ietf/pull/12>). I think we should now be in decent shape to proceed unless there is any other feedback to address?

> Do you think it is reasonable to complete the protocol and formal analysis in this time? Does the W3C have any milestones in this area? 

On your final questions. I think Feb 2021 provides us enough time to complete the protocol and the surrounding architecture. I’m not an expert in formal analysis but, since the core protocol design is currently quite stable, the design of appropriate models (e.g. using something like ProVerif) for performing this analysis shouldn’t be too difficult? (Someone please jump in here if I am incorrect).

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. Formal analysis of the
protocol will ensure that the security and privacy properties of the
protocol are well-understood and well-documented.

The following milestones (along with the approximate dates of
completion) will be used to judge the progress of the working group:

- Specification of protocol & surrounding architecture - February 2021.
- Specification of application-layer requirements (including HTTP integration) - June 2021.
- Specification of HTTP browser API (in coordination with W3C) - October 2021.