Subject: Re: [Privacy-pass] New drafts for IETF107

From: Alex Davidson <[email-masked]>
Date: Mon, 2 Mar 2020 11:57:25 +0000

Hi Steven,

Thanks for the feedback.

> On 26 Feb 2020, at 15:22, Steven Valdez <svaldez=[email-masked]> wrote:
> 
> Some initial comments from trying to write the API doc against the architecture doc:
> 
> - Having config_id and version seems like an odd set of names. config_id appears to just be the ciphersuite being used in the protocol, and version is the ID of the current set of key commitments.

You’re right, perhaps ciphersuite and commitment_id would be better?

> - The supports field seems like it would always contain issue and redeem, is there a use case where an set of keys would only ever be used for one or the other?

This is true, I was mainly leaving this open in case there were extensions that split the server functionality. For example, if we go down the public verifiability route, then it would be conceivable that only “redeem” would be supported?

> - The revoked scheme seems a bit weird (modifying previous keysets after the fact) and makes it hard to integrate with something like an append-only log. Wouldn't it be easier to just use to have a set of fields at the top level (under server_id) that list which keys are allowed to issue (always the newest key) and redeem (the current and previous keys).

I agree with this change, I’ll adopt this in a new version of the draft.

>  
> 
> On Fri, Feb 21, 2020 at 12:15 PM Alex Davidson <adavidson=[email-masked] <mailto:[email-masked]>> wrote:
> I’ve now pushed a WIP draft for the architecture document (draft-davidson-pp-architecture) to the same repo (https://github.com/alxdavids/privacy-pass-ietf/tree/master/drafts <https://github.com/alxdavids/privacy-pass-ietf/tree/master/drafts>).. There are a lot of TODOs still to address and I’m away for the next week, but I’m going to pick it back up when I return. Still aiming to have something submitted by the IETF 107 draft deadline on 9 March.
> 
> The pp-protocol document is not currently very prescriptive about the data formats of each of the types that are sent in protocol messages etc. This is something that I am going to start addressing and, ideally, I’m going to rewrite to be consistent with the TLS presentation language [RFC8446 <https://tools.ietf.org/html/rfc8446>] for compiling everything into standard formats (as it is also done in MLS, https://tools.ietf.org/html/draft-ietf-mls-protocol-08 <https://tools.ietf.org/html/draft-ietf-mls-protocol-08>).
> 
> Both drafts are still at a very early stage and so all feedback and contributions are very welcome (either here on the mailing list, or as GitHub issues/PRs are fine).
> 
> Alex
> 
>> On 12 Feb 2020, at 17:35, Alex Davidson <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi all,
>> 
>> I’ve taken an initial stab at a draft for the generic protocol overview at https://github.com/alxdavids/privacy-pass-ietf/blob/master/drafts/draft-davidson-pp-protocol/ <https://github.com/alxdavids/privacy-pass-ietf/blob/master/drafts/draft-davidson-pp-protocol/>. I refactored out most of the stuff from the existing draft-privacy-pass doc. The biggest change is that I decided to go with a wrapper API around the VOPRF API for constructing the protocol. I then provide a specific implementation of this API using the VOPRF protocol. I think this will help when devising extensions to the protocol as it will enable others to either: modify the VOPRF API that is used, or to just modify the way that the PP API is implemented altogether (in situations that may not use VOPRFs, such as in the case of public verifiability).
>> 
>> Some other things/questions to consider:
>> 
>> - I avoided any of the discussions around the architecture required for maintaining client privacy, this includes how key rotation works. I decided that these considerations are beyond the scope of the generic protocol description, but happy to hear contrasting opinions?
>> - The extension policy could probably do with some work. Since the privacy considerations will be in a separate document, currently I am assuming that any proposed extension satisfies the policies that will exist in each of the core three documents.
>> - Is the proposed API suitable? Are there any concerns for potential extensions using this API?
>> - I had to define some specific functionality for interacting with the groups used in the VOPRF implementation. Perhaps these can be moved to the VOPRF draft? 
>> - The provision of the security guarantees are lifted from https://petsymposium.org/2018/files/papers/issue3/popets-2018-0026.pdf <https://petsymposium.org/2018/files/papers/issue3/popets-2018-0026..pdf> and https://eprint.iacr.org/2020/072.pdf <https://eprint.iacr.org/2020/072.pdf> on the basis that the API implements the same protocol when using the VOPRF from draft-irtf-cfrg-voprf. This should probably be verified.
>> - There are some minor TODOs that need to be fixed, such as links to non-existent drafts.
>> 
>> I’ll start putting something together for the architecture document.
>> 
>> Cheers,
>> Alex
>> 
>>> On 6 Feb 2020, at 17:41, Alex Davidson <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Steven,
>>> 
>>>> On 6 Feb 2020, at 15:22, Steven Valdez <svaldez=[email-masked] <mailto:svaldez=[email-masked]>> wrote:
>>>> 
>>>> Yeah, it makes sense not to wait for the BoF to start iterating on initial docs. Are you planning on putting the split document in a git repo somewhere? Might make sense to set up a repo with all the base drafts in one place as separate files (ala the QUIC WG) so that people can file issues/PRs.
>>> 
>>> This is a good idea. I’ve repurposed the repo where I was hosting the draft charter previously to also include a space for working on the drafts here: https://github.com/alxdavids/privacy-pass-ietf/ <https://github.com/alxdavids/privacy-pass-ietf/>. I’ve placed the original draft-privacy-pass document in the drafts/ folder there, and we can use this space as a single location for contributing to these base drafts. Once a WG is formed, we can move this repo into a specific WG repo.
>>> 
>>>> 
>>>> I can take a stab at making a draft with a generic version of the integrations from the Trust Token API as a starting point for the third draft. I think fully specifying it will be dependent on the first two drafts, but having a starting point to feedback into laying out the earlier protocol/architecture descriptions would likely be useful for further iterating on those drafts.
>>> 
>>> This would be helpful, thanks.
>>> 
>>> Alex
>>> 
>>>> 
>>>> -Steven
>>>> 
>>>> On Thu, Feb 6, 2020 at 7:31 AM Alex Davidson <adavidson=[email-masked] <mailto:[email-masked]>> wrote:
>>>> Since there has been no more feedback on the charter that was proposed, I think that it may be useful to start work on drafting the three main documents that make up the protocol specification. Having some initial write-ups before the BoF @ IETF107 will also help to determine the agenda for the meeting if there any initial issues that arise from the writing process.
>>>> 
>>>> These three documents should cover the following:
>>>> 
>>>> - The generic description of the protocol, based on VOPRFs (or similar), including specification of security considerations, protocol messages and a framework for introducing extensions.
>>>> - The wider architecture for running the protocol: public interfaces, key rotation, privacy goals, applications, analysis of tracking potential/incentives for not following protocol.
>>>> - The API: specify how privacy pass data is integrated with HTTP requests/responses, and where key material is stored/how it is accessed.
>>>> 
>>>> Currently there is a single draft document (https://datatracker.ietf.org/doc/draft-privacy-pass/ <https://datatracker.ietf.org/doc/draft-privacy-pass/>) that includes considerations mostly spanning from the first two documents (although it is also includes some key management specifics). I can start to split this document into two parts that could be used to initiate the process of writing the initial drafts covering the first two points.
>>>> 
>>>> The third point is not well specified as of yet, but there are some applications such as the Trust Token API that integrate with HTTP already: https://github.com/WICG/trust-token-api <https://github.com/WICG/trust-token-api>.. Perhaps the third document necessarily needs to succeed the first two? But if anyone would be willing to start working on this document also, then that would be useful.
>>>> 
>>>> Alex
>>>> -- 
>>>> Privacy-pass mailing list
>>>> [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 <tel:(210)%20692-4742>
>> 
> 
> 
> 
> -- 
> 
> Steven Valdez |	 Chrome Privacy Sandbox |	 [email-masked] <mailto:[email-masked]> |	 210-692-4742

---

From: Steven Valdez <[email-masked]>
Date: Mon, 2 Mar 2020 09:28:11 -0500

On Mon, Mar 2, 2020 at 6:57 AM Alex Davidson <adavidson=
[email-masked]> wrote:

> Hi Steven,
>
> Thanks for the feedback.
>
> On 26 Feb 2020, at 15:22, Steven Valdez <
> svaldez=[email-masked]> wrote:
>
> - Having config_id and version seems like an odd set of names. config_id
> appears to just be the ciphersuite being used in the protocol, and version
> is the ID of the current set of key commitments.
>
>
This seems reasonable naming.

>
> - The supports field seems like it would always contain issue and redeem,
> is there a use case where an set of keys would only ever be used for one or
> the other?
>
>
> This is true, I was mainly leaving this open in case there were extensions
> that split the server functionality. For example, if we go down the public
> verifiability route, then it would be conceivable that only “redeem” would
> be supported?
>
I assume you mean only "issue" in the public verifiability case?  But seems
reasonable for extensibility.

>
> - The revoked scheme seems a bit weird (modifying previous keysets after
> the fact) and makes it hard to integrate with something like an append-only
> log. Wouldn't it be easier to just use to have a set of fields at the top
> level (under server_id) that list which keys are allowed to issue (always
> the newest key) and redeem (the current and previous keys).
>
>
> On Fri, Feb 21, 2020 at 12:15 PM Alex Davidson <adavidson=
> [email-masked]> wrote:
>
>> I’ve now pushed a WIP draft for the architecture
>> document (draft-davidson-pp-architecture) to the same repo (
>> https://github.com/alxdavids/privacy-pass-ietf/tree/master/drafts)..
>> There are a lot of TODOs still to address and I’m away for the next week,
>> but I’m going to pick it back up when I return. Still aiming to have
>> something submitted by the IETF 107 draft deadline on 9 March.
>>
>> The pp-protocol document is not currently very prescriptive about the
>> data formats of each of the types that are sent in protocol messages etc.
>> This is something that I am going to start addressing and, ideally, I’m
>> going to rewrite to be consistent with the TLS presentation language [
>> RFC8446 <https://tools.ietf.org/html/rfc8446>] for compiling everything
>> into standard formats (as it is also done in MLS,
>> https://tools.ietf.org/html/draft-ietf-mls-protocol-08).
>>
>> Both drafts are still at a very early stage and so all feedback and
>> contributions are very welcome (either here on the mailing list, or as
>> GitHub issues/PRs are fine).
>>
>> Alex
>>
>> On 12 Feb 2020, at 17:35, Alex Davidson <[email-masked]> wrote:
>>
>> Hi all,
>>
>> I’ve taken an initial stab at a draft for the generic protocol overview
>> at
>> https://github.com/alxdavids/privacy-pass-ietf/blob/master/drafts/draft-davidson-pp-protocol/.
>> I refactored out most of the stuff from the existing draft-privacy-pass
>> doc. The biggest change is that I decided to go with a wrapper API around
>> the VOPRF API for constructing the protocol. I then provide a specific
>> implementation of this API using the VOPRF protocol. I think this will help
>> when devising extensions to the protocol as it will enable others to
>> either: modify the VOPRF API that is used, or to just modify the way that
>> the PP API is implemented altogether (in situations that may not use
>> VOPRFs, such as in the case of public verifiability).
>>
>> - I avoided any of the discussions around the architecture required for
>> maintaining client privacy, this includes how key rotation works. I decided
>> that these considerations are beyond the scope of the generic protocol
>> description, but happy to hear contrasting opinions?
>> - The extension policy could probably do with some work. Since the
>> privacy considerations will be in a separate document, currently I am
>> assuming that any proposed extension satisfies the policies that will exist
>> in each of the core three documents.
>> - I had to define some specific functionality for interacting with the
>> groups used in the VOPRF implementation. Perhaps these can be moved to the
>> VOPRF draft?
>> - The provision of the security guarantees are lifted from
>> https://petsymposium.org/2018/files/papers/issue3/popets-2018-0026.pdf
>> <https://petsymposium.org/2018/files/papers/issue3/popets-2018-0026...pdf>
>>  and https://eprint.iacr.org/2020/072.pdf on the basis that the API
>> implements the same protocol when using the VOPRF from
>> draft-irtf-cfrg-voprf. This should probably be verified.
>> On 6 Feb 2020, at 17:41, Alex Davidson <[email-masked]> wrote:
>>
>> Hi Steven,
>>
>> On 6 Feb 2020, at 15:22, Steven Valdez <
>> svaldez=[email-masked]> wrote:
>>
>> Yeah, it makes sense not to wait for the BoF to start iterating on
>> initial docs. Are you planning on putting the split document in a git repo
>> somewhere? Might make sense to set up a repo with all the base drafts in
>> one place as separate files (ala the QUIC WG) so that people can file
>> issues/PRs.
>>
>>
>> This is a good idea. I’ve repurposed the repo where I was hosting the
>> draft charter previously to also include a space for working on the drafts
>> here: https://github.com/alxdavids/privacy-pass-ietf/. I’ve placed the
>> original draft-privacy-pass document in the drafts/ folder there, and we
>> can use this space as a single location for contributing to these base
>> drafts. Once a WG is formed, we can move this repo into a specific WG repo.
>>
>>
>> I can take a stab at making a draft with a generic version of the
>> integrations from the Trust Token API as a starting point for the third
>> draft. I think fully specifying it will be dependent on the first two
>> drafts, but having a starting point to feedback into laying out the earlier
>> protocol/architecture descriptions would likely be useful for further
>> iterating on those drafts.
>>
>>
>> On Thu, Feb 6, 2020 at 7:31 AM Alex Davidson <adavidson=
>> [email-masked] <[email-masked]>>
>> wrote:
>>
>>> Since there has been no more feedback on the charter that was proposed,
>>> I think that it may be useful to start work on drafting the three main
>>> documents that make up the protocol specification. Having some initial
>>> write-ups before the BoF @ IETF107 will also help to determine the agenda
>>> for the meeting if there any initial issues that arise from the writing
>>> process.
>>>
>>> - The generic description of the protocol, based on VOPRFs (or similar),
>>> including specification of security considerations, protocol messages and a
>>> framework for introducing extensions.
>>> - The wider architecture for running the protocol: public interfaces,
>>> key rotation, privacy goals, applications, analysis of tracking
>>> potential/incentives for not following protocol.
>>> - The API: specify how privacy pass data is integrated with HTTP
>>> requests/responses, and where key material is stored/how it is accessed.
>>>
>>> Currently there is a single draft document (
>>> https://datatracker.ietf.org/doc/draft-privacy-pass/) that includes
>>> considerations mostly spanning from the first two documents (although it is
>>> also includes some key management specifics). I can start to split this
>>> document into two parts that could be used to initiate the process of
>>> writing the initial drafts covering the first two points.
>>>
>>> The third point is not well specified as of yet, but there are some
>>> applications such as the Trust Token API that integrate with HTTP already:
>>> https://github.com/WICG/trust-token-api.. Perhaps the third document
>>> necessarily needs to succeed the first two? But if anyone would be willing
>>> to start working on this document also, then that would be useful.
>>>
>>> Alex
>>> --
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>>
>>
>>
>> --
>>
>> Steven Valdez |  Chrome Privacy Sandbox |  [email-masked] |
>> 210-692-4742 <(210)%20692-4742>
>>
>>
>>
>>
>>
>
> --
>
> Steven Valdez |  Chrome Privacy Sandbox |  [email-masked] |
> 210-692-4742 <(210)%20692-4742>
>
>
>

-- 

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

---

From: Alex Davidson <[email-masked]>
Date: Fri, 6 Mar 2020 17:57:03 +0000

Just as an update, we now have initial drafts for all of the three proposed documents at https://github.com/alxdavids/privacy-pass-ietf/tree/master/drafts/ <https://github.com/alxdavids/privacy-pass-ietf/tree/master/drafts/> (protocol, architecture, http-api contributed by Steven). We will be submitting these as individual drafts before the 09 March deadline to be discussed at the BoF. Any feedback is welcome!

> On 2 Mar 2020, at 14:28, Steven Valdez <svaldez=[email-masked]> wrote:
> 
> 
> 
> On Mon, Mar 2, 2020 at 6:57 AM Alex Davidson <adavidson=[email-masked] <mailto:[email-masked]>> wrote:
> Hi Steven,
> 
> Thanks for the feedback.
> 
>> On 26 Feb 2020, at 15:22, Steven Valdez <svaldez=[email-masked] <mailto:svaldez=[email-masked]>> wrote:
>> 
> I assume you mean only "issue" in the public verifiability case?  But seems reasonable for extensibility.
> 
>>> - The provision of the security guarantees are lifted from https://petsymposium.org/2018/files/papers/issue3/popets-2018-0026.pdf <https://petsymposium.org/2018/files/papers/issue3/popets-2018-0026...pdf> and https://eprint.iacr.org/2020/072.pdf <https://eprint..iacr.org/2020/072.pdf> on the basis that the API implements the same protocol when using the VOPRF from draft-irtf-cfrg-voprf. This should probably be verified.
>>>> On 6 Feb 2020, at 17:41, Alex Davidson <[email-masked] <mailto:adavidson@cloudflare..com>> wrote:
>>>> 
>>>> Hi Steven,
>>>>

---

From: Alex Davidson <[email-masked]>
Date: Mon, 9 Mar 2020 10:53:12 +0000

The three drafts have now been submitted:

- Protocol: https://tools.ietf.org/html/draft-davidson-pp-protocol-00 <https://tools.ietf.org/html/draft-davidson-pp-protocol-00>
- Architecture: https://tools.ietf.org/html/draft-davidson-pp-architecture-00 <https://tools.ietf.org/html/draft-davidson-pp-architecture-00>
- HTTP API: https://tools.ietf.org/html/draft-svaldez-pp-http-api-00 <https://tools.ietf.org/html/draft-svaldez-pp-http-api-00>

Alex

> On 6 Mar 2020, at 17:57, Alex Davidson <[email-masked]> wrote:
> 
>> On 2 Mar 2020, at 14:28, Steven Valdez <svaldez=[email-masked] <mailto:svaldez=[email-masked]>> wrote:
>> 
>> 
>>

---

From: Sofía Celi <[email-masked]>
Date: Tue, 24 Mar 2020 01:55:05 -0500

Hi, Alex!

Thanks so much for sending this!

I have some points after reviewing the documents. I'll first send the
notes for the draft of the protocol, as I have to put my notes for the
other ones in place ;)

The first thing I noticed is that there should be consistency with the
naming of variables:

- Sometimes a server is referred as 'server', while other times as
'Privacy Pass server'. I think the document always refers to a Privacy
Pass server; but a reader might think there are two kinds of servers.
The same for when using 'client' and 'Privacy Pass Client'.
- Most of the inside values of the defined structs have a
larger/meaningful name.. so maybe 'ServerUpdate s', should change to
something else.
- The struct 'ClientIssuanceInput' has a 'ClientIssuanceProcessing
client_data' value, which holds inside a 'opaque
client_data<1..2^32-1>', maybe it will be good to change the name of the
inside 'client_data', as it can become confused with the external one.
- I was thinking that maybe all of the structs should be named according
to who deals with them as 'ClientIssuanceInput' or 'ServerUpdate'. This
can be applied to 'IssuanceResponse' or 'IssuanceMessage'.
- Some variables change names, like 'cfg', which can be also 'srv_cfg'
or 'cli_cfg'. Maybe they should always be called in the right places
'srv_cfg' and 'cli_cfg'.
- There is other naming consistency issues that I can fix on a PR. But
the idea was to be consistent on them ;)

- The definition 'Commitment' is defined but never used in the document.

- On this section:
"""
* At any one time, we assume that the Server uses only one
configuration containing their ciphersuite choice along with their
secret key data.
* We assume that the client has access to a global directory of the
current configurations used by all Privacy Pass servers.
"""
It seems to imply that the client have access to the configuration which
includes the ciphersuite and server secrets.. Maybe here it will be good
to clarify that clients only have access to the public part of the
configuration of servers.

- The document should probably clarify that it will only refer to
communication between one server and a client. It should also probably
state that the handling of different clients and servers is the
responsibility of the architecture document. I was think maybe a section
with the limitations/out-of-scope of the draft, and where on the other
drafts they are addressed.

- The architecture draft states the possibility of the existence of
malicious servers that can rotate keys in a short time frame. Something
that maybe also needs to be think about is the possibility of malicious
servers deleting the storage of valid inputs (used to protect against
double spending). I don't know how possible this can be, and how to
protect.. but I was just wondering if it has been thought.

I can create issues for these points and send some PRs on them, so let
me know if you agree on them ;)

Thanks!

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

---

From: Alex Davidson <[email-masked]>
Date: Tue, 24 Mar 2020 12:40:19 +0000

Hi Sofia,

Thanks for taking the time to read through the drafts.

> On 24 Mar 2020, at 06:55, Sofía Celi <[email-masked]> wrote:
> 
> Hi, Alex!
> 

The points that you’ve raised above all make sense to me. If you would be interested in submitting an issue/PR for solving them, that would be really useful and I would be happy to review it.

> drafts they are addressed.

Both of the above clarifications make sense to me. In particular, specifically laying out the scope of the draft is something that we should definitely do to avoid confusion.

> protect.. but I was just wondering if it has been thought.

I guess this is a possibility. However, a server should only really maintain the double-spend index for their own security (to prevent clients from spending the same token over and over again). If a server decides to delete this storage, then really they have only harmed themselves. So I’m not sure if we need to cover this point specifically, other than mentioning that the server SHOULD maintain a double-spend index as detailed in the document.

> me know if you agree on them ;)

Sure! Documenting the consistency and clarification points on the GitHub repo would be useful.

Thanks,
Alex

---

From: Sofía Celi <[email-masked]>
Date: Wed, 25 Mar 2020 02:35:26 -0500

Hi, Alex!
> The points that you’ve raised above all make sense to me. If you would be interested in submitting an issue/PR for solving them, that would be really useful and I would be happy to review it.

Just sent it ;) I added some grammar corrections as well.
While doing the PR, I also realized that it is not clear when the
'Issuance message' is sent. It seems to not be the output of any of the
API functions... I'm not sure how that one works..

After reading the architecture document, I thought that:

- Maybe it will be nice to give an example for the unique identifier for
the client id
- It will be nice to define what anonymity means in the draft, maybe
taking the definitions of some papers that have defined the different
terms around anonymity.
- This section is a little unclear for me:
"""
In addition, we RECOMMEND that trusted registries indicate at all
times which issuers are deemed to be active.
"""
How will the registries determine which issuers are active?
- It will be nice to also recommend a time for when servers can rotate
their signing keys.
- It also seems to have some variable naming consistency issues that
I'll fix in a PR if it is ok ;)

> I guess this is a possibility. However, a server should only really maintain the double-spend index for their own security (to prevent clients from spending the same token over and over again). If…

Oh, that is right! It makes sense.

Thanks so much!

---

From: Mariana Raykova <[email-masked]>
Date: Wed, 25 Mar 2020 18:39:08 -0400

Hi Alex,

Thanks for preparing the drafts with Steven.

I would like to propose adding to the architecture document the private
metadata bit as a possible extension as defined in our paper
https://eprint.iacr.org/2020/072.pdf. We discussed this in the meeting in
New York as one of the extensions. I know that we have decided that the
actual protocols will be described in a separate CFRG document but I would
like to have the functionality as an extension to the Privacy Pass
functionality included in the document that lists several different
extensions. For example, to achieve a single-issuer with
forwarding-verifier requires significant changes to the Privacy Pass
construction and similarly other applications with general ZKPs, changes
that are on the order of the changes to achieve private metadata but.

I think in another email thread there was a discussion about other
proposals in this space and Alex mentioned that partially blind signatures
can be viewed as an extension of the Privacy Pass framework, I think the
private metadata bit falls in a similar category. The related work of our
paper has an overview of some existing work that may also be relevant.

thanks,
Mariana

On Wed, Mar 25, 2020 at 3:35 AM Sofía Celi <[email-masked]> wrote:

> Hi, Alex!
> > The points that you’ve raised above all make sense to me. If you would
> be interested in submitting an issue/PR for solving them, that would be
> really useful and I would be happy to review it.
>
> > I guess this is a possibility. However, a server should only really
> maintain the double-spend index for their own security (to prevent clients
> from spending the same token over and over again). If a server decides to
> delete this storage, then really they have only harmed themselves. So I’m
> not sure if we need to cover this point specifically, other than mentioning
> that the server SHOULD maintain a double-spend index as detailed in the
> document.
>

---

From: Alex Davidson <[email-masked]>
Date: Thu, 26 Mar 2020 15:01:32 +0000

Hi all,

@Mariana: Thanks for bring up. I agree that adding a discussion on the consideration of attaching some small amount of metadata to tokens that are issued is something that we will want to bring up the core documents. In particular, a potential path forward would be to add an additional implementation of the Privacy Pass API in the protocol draft based on the https://eprint.iacr.org/2020/072.pdf <https://eprint.iacr.org/2020/072.pdf> construction that incorporates the additional metadata bit, to go alongside the existing implementation. Then we would address the privacy analysis of incorporating this extra bit in the architecture document, though I think this will be relatively straightforward. Would be interested to hear what other think about doing this.

This does raise the question of whether we would want to be even more general in the architecture document and discuss the privacy impacts of adding more arbitrary metadata to tokens, up to a certain amount of bits. It’s not clear what the implications of doing this would be, so adding a wider discussion and analysis may well be worthwhile?

> On 25 Mar 2020, at 22:39, Mariana Raykova <marianar=[email-masked]> wrote:
> 
> Hi Alex,
> 
> I would like to propose adding to the architecture document the private metadata bit as a possible extension as defined in our paper https://eprint.iacr.org/2020/072.pdf <https://eprint.iacr.org/2020/072.pdf>. We discussed this in the meeting in New York as one of the extensions. I know that we have decided that the actual protocols will be described in a separate CFRG document but I would like to have the functionality as an extension to the Privacy Pass functionality included in the document that lists several different extensions. For example, to achieve a single-issuer with forwarding-verifier requires significant changes to the Privacy Pass construction and similarly other applications with general ZKPs, changes that are on the order of the changes to achieve private metadata but. 
> 
> I think in another email thread there was a discussion about other proposals in this space and Alex mentioned that partially blind signatures can be viewed as an extension of the Privacy Pass framework, I think the private metadata bit falls in a similar category. The related work of our paper has an overview of some existing work that may also be relevant.
> 
> thanks,
> Mariana

@Sofia: Thanks for raising these points. I’ve inlined my reply, but please feel free to raise issues on the GitHub repo for the things that you have highlighted (I can also do this once I get a moment).

> 
> On Wed, Mar 25, 2020 at 3:35 AM Sofía Celi <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, Alex!

That’s true, I think in the protocol it just needs to be made more clear that the IssuanceMessage is constructed by the client from the ClientIssuanceElement data that it creates. However, we could probably also condense these types down into one that is also sent on the wire.

> taking the definitions of some papers that have defined the different

Yes, this is a good point. We should be clearer on what definition of anonymity we are considering.

> How will the registries determine which issuers are active?

Also a good point. I think this comes into the way that we detect and act against servers act maliciously. The concept of an active issuer is maintained to ensure that we only have a fixed number of issuers at any one time.

> - It will be nice to also recommend a time for when servers can rotate

Either we will want to consider fixed time periods, or the configuration manager will need to monitor the times when updates have occurred and decide whether to accept them or not. This is the approach that currently exists, but I think this is something that it would also be useful to get a broader consensus on.

> I'll fix in a PR if it is ok ;)

Sure, by all means!

Cheers,
Alex

---

From: Mariana Raykova <[email-masked]>
Date: Thu, 26 Mar 2020 14:22:56 -0400

On Thu, Mar 26, 2020 at 11:01 AM Alex Davidson <adavidson=
[email-masked]> wrote:

> Hi all,
>
> @Mariana: Thanks for bring up. I agree that adding a discussion on the
> consideration of attaching some small amount of metadata to tokens that are
> issued is something that we will want to bring up the core documents. In
> particular, a potential path forward would be to add an additional
> implementation of the Privacy Pass API in the protocol draft based on the
> https://eprint.iacr.org/2020/072.pdf construction that incorporates the
> additional metadata bit, to go alongside the existing implementation. Then
> we would address the privacy analysis of incorporating this extra bit in
> the architecture document, though I think this will be relatively
> straightforward. Would be interested to hear what other think about doing
> this.
>

The extra bit is equivalent to having two different signing keys on the
side of the server in terms of the unlinkability for the clients.

>
> This does raise the question of whether we would want to be even more
> general in the architecture document and discuss the privacy impacts of
> adding more arbitrary metadata to tokens, up to a certain amount of bits.
> It’s not clear what the implications of doing this would be, so adding a
> wider discussion and analysis may well be worthwhile?
>

I think the privacy implications of the metadata bits can be mapped onto
the analysis for different numbers of active keys for the server. I also
wanted to make the point that for several of the listed extension we do not
go really into detailed analysis of their additional formal security
properties and I do not think this is necessary as probably any specific
protocol for any of the extensions should come its own security analysis. I
think the case for the metadata should be similar.

>
> On 25 Mar 2020, at 22:39, Mariana Raykova <
> marianar=[email-masked]> wrote:
>
> Hi Alex,
>
> @Sofia: Thanks for raising these points. I’ve inlined my reply, but please
> feel free to raise issues on the GitHub repo for the things that you have
> highlighted (I can also do this once I get a moment).
>
>
> That’s true, I think in the protocol it just needs to be made more clear
> that the IssuanceMessage is constructed by the client from the
> ClientIssuanceElement data that it creates. However, we could probably also
> condense these types down into one that is also sent on the wire.
>
>
> Also a good point. I think this comes into the way that we detect and act
> against servers act maliciously. The concept of an active issuer is
> maintained to ensure that we only have a fixed number of issuers at any one
> time.
>
> Either we will want to consider fixed time periods, or the configuration
> manager will need to monitor the times when updates have occurred and
> decide whether to accept them or not. This is the approach that currently
> exists, but I think this is something that it would also be useful to get a
> broader consensus on.
>

---

From: Steven Valdez <[email-masked]>
Date: Thu, 26 Mar 2020 14:42:07 -0400

> think the case for the metadata should be similar.

I suspect we will want to go into further discussion in the drafts about
the implication of multiple active keys with non-standard key rotation
schedules that having arbitrary metadata will need. Currently without
metadata bits, you only really have a single active key, while with
metadata there are different privacy properties from having multiple active
keys. Similarly the policies that clients can enforce may differ when
multiple active keys are being used, versus a single advancing active key
in normal key rotation. Generally it seems worthwhile to have at least a
basic security/privacy analysis of any 'core' extensions included in the
documents by the working group.

>> https://eprint.iacr.org/2020/072.pdf. We discussed this in the meeting
>> in New York as one of the extensions. I know that we have decided that the
>> @Sofia: Thanks for raising these points. I’ve inlined my reply, but
>> please feel free to raise issues on the GitHub repo for the things that you
>> have highlighted (I can also do this once I get a moment).
>>
>>

--