# PRIVACY PASS {#privacy-pass} ## Administrivia {#administrivia} ## Implementation Experience {#implementation-experience} Tommy presenting various deployments: Two GitHub implementations. Deployment experience from non-open source implementations. Shown at WWDC22, Captcha replacement, aiming to increase awareness of privacy pass. Cloudflare and Fastly provide issuers. Based on early betas 35K tokens issued per day. Nick Dotty: Have you considered the problem of over reliance? What do we do to make developers not expect get this all the time? Tommy Pauly: We should give advice about this in the document. This can be enabled manually by the user. Could be useful to have it randomly not be performed some of the time. ## Core Document Status {#core-document-status} Presented by Tommy Pauly Pretty mature from techical perspective. Getting closer to last call. Tommy presenting recent changes to the documents. ### Open Issues {#open-issues} 143 - New registires defined by the documents. Where does this go? "PRivacy Pass Parameters" page What review policy? "Specification reqired" Chris Wood: Seems fine, can we specify required certain properties for the registry. Tommy Pauly: Right advice to experts needs to be specified David Schinazi: How is this encoded, varints? Tommy Pauly: 16 bit fields. David Schinazi: Varints allows for a lot more experimentation without specification required. Tommy Pauly: Reserve experimental values range? David Schinazi: Provisional allocations. Tommy Pauly: Provisional allocations is compatible with "specification required" David Schinazi: Do like quic, some of the space is "specification requruired" and some does not be Issue 141 - Attestation Compromise What does the ecosystem do if the attestation system starts doing the wrong thing? Solution is likely deployment specific. Chris Wood: Nothing specific in mind right now, will likely vary based on deployment model and the config of different parties. This is an exceptional event, applications should have a way to deal with it. Tommy Pauly: If some party does bad things it needs to be untrusted. Chris Wood: Temporary failures should not lead to permanent untrust. ### Questions? WGLC? {#questions-wglc} Sofia Celi: Two questions: 1: It seems like it's going to be a last call. Does this depend on the WGLC CFRG of documents? 2: Entities can be compromised and collude etc. Should there be a more formal document about the implications of compromised or colluding entities? Tommy: The document talks a bit about analysis. Totally fine with further documents that talk about specific analysis. There are several deployments where this is relevant. Rifaat Shekh-Yusef: Elaborate the trust betwen parties of the solution? Tommy Pauly: Trust dependency between enteties - transitive trust and credibility chain between attesters and issuers .. ? Chris Wood: We do not need to block on having gone throuhg all the process in CFRG to move forward here. We expect implementers to implement properly. We assume that they follow the specified behavior. ## Rate Limited Token Issuance {#rate-limited-token-issuance} Presented by Chris Wood. Update on document presented last time. Adoption call ongoing. High level overview. Presenting redemption and issuance protocols. Problem: Basic issuance protocol does not allow per-client rate-limiting. There is no concept of state in the issuance flow. Rate limiting is useful for several things. Can we add support without compromising privacy? Chris presenting how rate limiting typically works in practice. Rate limiting design constraints: Origin should only learn that that the does not exceed the rate limit. Origin adoption should be as simple as basic privacy pass. Issuance should be as stateless as possible. Client origin pairs should not be linked by issuer or attesters. Extends basic issuance protocol: Issuers associate origin with challenge. Attester learn stable mapping between per-client and per-origin secret, without learning per-origin information. Presents some example diagrams. Attester state increases, per-origin state per client. Privacy properties: Attester learns stable mapping between client and origin secrets. Two interoperable implementations. Security analysis done, did not capture origin swapping issue (issue: xx) Jonathan: Is this an ??.. attack? Client spoofing Chris Wood: Assumption is that attestation ensures that this does not happen. The protocol assumes that the client attester relationship prevents this from happening. Mirja Kühlewind: Have you considered reversing the rate limiting. Chris Wood: This was considered in previous version of the document, but would leak more information. Nick Doty: Have we established that this metering will be effective for all use cases, e.g. anti-abuse will a single threshold be sufficent? Chris Wood: No immideate answer to you. Tommy: We can't know how everything plays out. Anti-fraud community, there are origins for which this improves things compared to basic privacy pass, dosen't provide solutions for the full set of problems. Benjamin Schwartz: This document is currently undeer an open adoption call, please provide your feedback to the list. ## Key Consistence and Discovery {#key-consistence-and-discovery} Presented by Chris Wood. Motivation: Many protocols coming up that require clients to discover public keys. Privacy Pass, OHTTP, Tor. Common requirements - Unlikability - Server cannot link key to specific user. Authenticity. Every server has a consistent view of these properties and this view is correct. Different approaches with different tradeoffs. Single trusted proxy, multiple less trusted proxies, external database (bulletin board). Propose to adopt as informational draft to complement deployed solutions and proposed specs. Helps inform the discussion. Tommy Pauly: This is clearly very important. Don't know which WG it belongs to, does not matter that much either. Could the approach of double check be described more explcitily? We could talk about techniques here and let other protocols select techniques. Chris Wood: Sounds like a good idea, could be done in various ways. Benjamin Schwartz: The authors have requested and adoption call, the chairs will consider that. An announcement can be made at the list, please review the document and be ready to comment.