[Privacy-pass] Re: WGLC for Rate-Limited Token Issuance

[Christopher Wood <[e-mail]>]

Hi Watson,

Please see inline below.

> On Jun 21, 2024, at 10:11 PM, Watson Ladd <[e-mail]> wrote:
> 
> Dear Privacy pass participants,
> 
> I think this document unfortunately complicates the privacy and
> centralization story. Origins must pick Issuers they trust, but the
> client's privacy in the Origin  vis a vis the Attester depends on the
> number of Origins that trust the Issuer. Attesters also need to be
> trusted as they ultimately enforce the limits. This is in tension with
> non-collusion requirements. There's some text here on that, but I'd
> like a better understanding of why this is realistic, probably because
> of some emails rather than more text.

This is true, but not a new trust assumption for Privacy Pass. I’m also not sure what you mean by this being in tension with non-collusion requirements. Where is the tension?

> Section 7 I had to puzzle over: it was not clear to me for a while how
> the attestor learns sk_blind.  It's also not clear to me what F is
> supposed to be in that section, or what security properties this dance
> is supposed to have. F doesn't appear to be defined anywhere. In fact
> after digging into this some more I'm confused. This seems like the
> sort of thing where we need a clear statement of the properties being
> looked for to have security, and unwinding the Key Blinding ID
> references I don't think the properties are the ones analyzed by the
> Tor proposal. There's some messiness around the wrapping of it, which
> makes me wary. I think there's also assumptions about the commutivity
> of blinding and unblinding that require looking into the Key Blinding
> mechanism too much.

F is effectively a PRF, computed like an OPRF. It computes H(g^x, g^k) for client secret x and origin secret k. This is not quite the same as the 2HashDH OPRF, though we can certainly add more details and a proof (sketch) for why we believe this holds if that would be helpful.

> 
> I think Section 10 should also recommend client origin alias rotation intervals.
> 
> Minor nit: in 5.1.1 I think "Attester will enforce if" should be
> "Attester will decide if"
> 
> HTTP nit: I don't understand why headers are being used for some of
> the per-request information conveyances vs adding to the data
> structures in play.
> 
> The timing is a little unfortunate: we've been able to put together an
> approach that gets a lot of the desirata for more features across
> privacy pass applications with one token type, and will write it up
> before IETF 120, but it would be some time before we could get it to
> WGLC state. We can do real rate limits with client privacy, not just
> the pseudonym approach from earlier.

It’s great to see that there are alternative proposals! Fortunately, we don’t need to choose one or the other. In fact, we opted to downgrade this specification to experimental on the basis that there might be different ways to solve the problem with a more palatable set of tradeoffs. However, we feel as though the protocol is fine to ship as-is (document edits notwithstanding), given implementation interop that’s been achieved and the complementary security analysis [1,2] on its constituent parts.

[1] https://eprint.iacr.org/2023/1805.pdf
[2] https://eprint.iacr.org/2023/380.pdf

> I think this document needs some revision and more analysis: I don't
> think its ready to proceed, mainly because of Section 7.

As above, we can add this analysis for section 7 if the WG believes that’s essential.

Best,
Chris