# PrivacyPass Notes IETF 116 Yokohama {#privacypass-notes-ietf-116-yokohama} ## Agenda {#agenda} * Administrivia - Chairs (5 Min) * WG Document Update - Chairs (10 Min) * Rate Limit Tokens - Pauly (25 Min) draft-ietf-privacypass-rate-limit-tokens * Batched Tokens - Robert (20 Min) draft-robert-privacypass-batched-tokens * Future Directions: Key Consistency - Schwartz (15 Min) * Future Directions: Public Metadata Tokens - Hendrickson (15 Min) ## Minutes {#minutes} No agenda bashing ### Rate limit tokens {#rate-limit-tokens} Rate-limit tokens are a variant of the publicly verifiable blind RSA tokens that allow rate-limiting. Attestors implement this with "buckets". New section on penalization of mis-behaving issuers and clients. This is to avoid information leaking by strategically denying token issuance. Heuristics suggested for detecting exceptional cases of protocol violation. Update on suggested derivation of Anonymous Origin ID to include issuer name. Updated suggestions on what origin name to pick in certain more obscure scenarios. Since the state for rate limiting is on the attester, the rate limit is per attester. Having many attesters increases the rate limit, raising the problem of centralisation. Issue to be filed discussing this. Bikeshedding time! "Anonymous Origin ID" and "Anonymous Issuer Origin ID" are confusing. Call for better ideas. Not a good use of time in meetings, will discuss later. Work needed on key consistency strategies given there are more keys in this spec. 3 or 4 implementations of this spec exist. No questions from the room ### Batched tokens {#batched-tokens} Privately Verifiable Tokens can be expensive to issue in high numbers, due to the slow P384 primitive. Issue multiple tokens in response to a single TokenChallenge, reducing the size and cos of the proof per token. Security consideration mitigations: * limit issuance (e.g. rate limit) * rotating keys regularly * define a new token type with a larger group Performance chart of this draft shown in slides. 2 interoperable implementations: * privacypass in Rust * pat-go in Go Q from Steven: Broad support for this draft. We don't want to rotate keys too frequently, so perhaps other mitigations should be considered to avoid frequent key rotation due to the privacy implications of that. Action item: call for adoption on list ### Key consistency {#key-consistency} No draft associated with this presentation. WG charger says we should describe mechanisms that stop issuers from presenting material to de-anonymize clients. Key-consistency draft discusses this at length. All architectures discussed require at least one trusted party. W3C Private State Tokens assumes we are going to solve the problem of privacypass for the web, but we have not, yet. If privacypass does not solve the problem of key consistency the PST draft contains a stopgap solution that's highly consolidating for both Issuers and User-Agents. This is probably a good reason to try and do better. Proposed design goals would require: * a concrete key consistency protocol * excluding most broadcast architectures * excluding most diirectory discovery protocols * excluding trusted proxy archiceture Paths forward: * ignore it * solve it later * solve it now draft-schwartz-ohai-consistency-doublecheck as a possible solution Q from Tommy: Definitely in scope, total agreeement on design goals. Where the attestor works as a proxy to the issuer, all the information is almost all already in place to enable this. Q from Eric Orth: Difficult problem, but a pretty good list of goals has been presented. If we don't set out a spec people will get it wrong, so thinks its worthwile to publish at least one spec. Q from Christopher: This is generally speaking not a solved problem, it just hasn't been solved for all use cases yet. We have solutions now that work in practice. Q from Steven: Different use-cases require different models. Splitting issuer and attestor does somewhat kick the who gets to be the issuer question down the road. Q from Matthew: Happy to see work on formalising this instead of everyone doing their own this. Q from Christopher: PST and privacypass are not currently interoperable, they may be in future. We shouldn't do key-consistency on just PST, and instead focus on the more general privacypass. Q from Steven: Maybe we should explixitly state that issuer and attester must be seperate. Q from Tommy: Either we have one document with two sections for joint and split. If that's too much work split it into two documents. This will serve the W3C well whatever model they come up with. Privacy Pass is not the only place with a consistency problem, oblivious HTTP has a similar problem. It might be interesting to think about how many of these usecases we can satisfy. Q from Christopher: Are the W3C expectations of the WG still up to date? Should we reset expectations about what this group provides to the layer above. Call for volunteers for a Design Team. ### Public Metadata Tokens {#public-metadata-tokens} Metadata is visible to all parties in privacy-pass. Encoded arbitrary bits. Differentiating groups of clients with blind RSA requires an issuer per group. Token expiry bound by speed of key rotation. Every new public key must propagate completely to every origin. Q from Martin: differentiation sounds like a bad requirement and directly at odds with the goals of the group. This provides fingerprining possibilities. This already exists where multiple issuers might exist for different groups. Its not really a privacy issuer to differentiate client version at sign-in time. Q from Martin: Where does the metadata come from? The client? What causes the client to provide this information. Q from Christopher: expiration of tokens was alluded to. For that its easy for a client to know that its not providing any information that may identfy it. In other cases its not so clear. Martin: The issue is the origin learning information that it would not already have. Chrstopher: Agreed, there be dragons is the thing here. Proving to the world that the metadata is private is the difficult part, this is discussed in the draft but needs expansion. draft-amjad-cfrg-partially-blind-rsa draft-hendrickson-privacypass-public-metadata Christopher: Relations to the key consistency problem that was just discussed, maybe the future design team should discuss entire configuration consistency. David: Google is considering using this, would love to see adoption and feedback from WG Christopher: we should consider adopting this draft ### AOB {#aob} None! See you all at IETF117.