Re: [Privacy-pass] Searching for simplicity

[Tommy Pauly <[e-mail]>]

> On Mar 24, 2022, at 1:34 PM, Ben Schwartz <bemasc=[e-mail]> wrote:
> 
> Hi all,
> 
> Not as chair.
> 
> I found the discussion today of "preventing abusive account creation", and the goal of "ensuring that no single party knows both the stable client ID and the origin name", very helpful to understand the requirements for the rate-limiting proposal.  After reviewing the draft, it seems that it has already been simplified substantially (no Schnorr proofs!), so I can certainly believe that this is the simplest instantiation.
> 
Thanks for reviewing/re-reading! The goal was certainly to simplify.

> Some questions for the authors:
>  * Are you assuming that the client enforces some limit on the number of distinct Issuers, as discussed in other Privacy Pass drafts?  If any origin operates its own private Issuer, the Attester ends up learning that the user visited that origin, violating the separation goal.  Do you intend to prevent this?

Yes, a 1:1 relationship between Issuer and Origin would indeed violate the goal of separating information from the Attester. It still doesn’t allow the Attester to know the origin state, but it does tell the Attester more about the origin identity than we’d want.

I think we don’t clearly state a requirement that the Client and/or Attester need to collectively check that there are a sufficient number of origins served by each issuer (conversely, that there aren’t too many issuers). As we’re considering Attester deployments, it would be a requirement when onboarding an Issuer to ensure that there is a sufficient set of origins. We can open an issue to add this text.

>  * The draft notes that "The Origin does not learn which Attester was used by a Client for issuance".  Is this a requirement?  Would relaxing it allow any simplifications?  Does this hold true if there is an Issuer that issues tokens to only one Attester?

Chris can correct me if I’m wrong, but I believe this is more of a statement of the properties rather than a strict requirement. You are indeed correct that an Issuer that only ever allowed one Attester would then be able to tell an Origin what Attester was used implicitly.

> 
> I would also appreciate some thought on the post-compromise properties of this system, e.g. describing the downstream implications of a misbehavior of one of these parties.

Yes, that’s a great point. There should definitely be discussion of what could be reconstructed if parties logged and leaked data, etc.

Best,
Tommy
> 
> Thanks,
> Ben Schwartz
> -- 
> Privacy-pass mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/privacy-pass