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

[Christopher Wood <[e-mail]>]

> On Jun 26, 2024, at 7:52 PM, Watson Ladd <[e-mail]> wrote:
> 
> 
> 
> On Wed, Jun 26, 2024 at 12:38 PM Christopher Wood <[e-mail] <mailto:[e-mail]>> wrote:
>> Hi Watson,
>> 
>> Please see inline below.
>> 
>>> On Jun 21, 2024, at 10:11 PM, Watson Ladd <[e-mail] <mailto:[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?
> 
> If I understand correctly, the Attester needs to be instructed by the Origin what the rate limits are, and the Issuer needs to maintain state based on the volume of requests from the Origin.

Both of these are incorrect (and point to things we should clarify in the document!). The Origin tells the Issuer what the rate limit is out-of-band, and the Issuer relays this to the Attester during the issuance flow. The Issuer is stateless. The Attester keeps state for enforcing rate limits across all (client, origin) tuples. I filed this issue <https://github.com/ietf-wg-privacypass/draft-ietf-privacypass-rate-limit-tokens/issues/32> to track clarifying these points.

> Both the Issuer and Attester know why they are incurring these costs and who benefits, and need some way to pay for it. He who pays the piper calls the tune. In the baseline privacy pass protocol privacy exists even when Origin, Issuer, Attester are the same. This isn't new, it's been discussed in RFC 9576, but I think that the more the origin needs to interact with both parties, and the less observable collusive behavior is the harder it is to justify actual separateness.

Agreed, which is why I feel this protocol isn’t meant for web use cases. It would take a lot of work to make it scale and has been pointed out it’s not clear that can be done safely. I filed this issue <https://github.com/ietf-wg-privacypass/draft-ietf-privacypass-rate-limit-tokens/issues/33> to track documenting the protocol’s limitations.

> 
>> 
>>> 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.
> 
> I'll let other people weigh in: I personally think it would help as right now section 7 is pretty confusing. But once that's cleared up I think it's ready.

Sounds good. Would you be willing to review PRs that clarify section 7? I filed this issue <https://github.com/ietf-wg-privacypass/draft-ietf-privacypass-rate-limit-tokens/issues/34> to track section 7 improvements.

Best,
Chris