Re: [Privacy-pass] New drafts for IETF107

[Alex Davidson <[e-mail]>]

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=[e-mail]> wrote:
> 
> 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 <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 <[e-mail] <mailto:[e-mail]>> 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.
> 
> 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..

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.

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

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

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

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
> their signing keys.

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.

> - It also seems to have some variable naming consistency issues that
> I'll fix in a PR if it is ok ;)

Sure, by all means!

Cheers,
Alex