Re: [Privacy-pass] New drafts for IETF107

[Mariana Raykova <[e-mail]>]

On Thu, Mar 26, 2020 at 11:01 AM Alex Davidson <adavidson=
[e-mail]> 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=[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. 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]> 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
>