# Privacy Pass at IETF 110 -------------------- ### Friday, March 12, 2021 ### Chairs: Ben Schwartz, Joe Salowey ### Note Taker: Watson Ladd ----------------- # Adminstrative * Note Well * Agenda bash ----------------------------- # Anonymity issuer issue ----------------------------- ## Review the Issuer cardinality arithmetic from -architecture (Alex Davidson, 10 min) * Specific issue about cardinality and impact unlikability * Analyzing privacy preserving ecosystems around protocol * Unlinkability between client redemption and issuance isn't automatic * Similar to other architecture docs * Minor changes: token metadata and expiry * Open issue: Number of issuers allowed in privacy pass ecosystem * Unlikability rests upon redemptions: if succeeds, was a valid token * Each issuer creates a distinct class token. Redeem multiple different issuers, anonymity set reduced to people who got all the tokens * In some cases proxying via third parties, or publically doable * Example: two issuers, three people. Charlie is the only one who got both tokens, poor him * Worst case every issuer drops privacy one bit * Independent of anything else (metadata, key rotation) * Section 10 generic ecosystem has the exact equation * metadata hurts more * Get 17 issuers under reasonable assumptions * Gets even smallers * What if we reduce by restricting redemptions? * Limit issuers client redeems with? * Client can only redeem for very limited profile wider ecosystem has many, privacy moved to client held tokens * Open questions: How do clients decide, enforcing these contexts, application specific, what architecture guidance is required? Implementors and applications ## Multi-context architectures for Privacy Pass (Steven Valdez, 10 min) * Currently all privacy assumes one client giant * In HTTP top level sites have own context. Cross-context sharing heavily restricted. Mostly boundaries. * Devices: context is application * In global context issuers together build fingerprints with collaborating issuers * Shared redemption contexts fragment issuers, reduces leakage * Each redemption has privacy implications * To get this right: strong boundaries, unjoinable, application speciific linkages * Hard coded limits on issuers that get used * Whether or not having a token any interaction has to count against context * Reason: trying can dig out what tokens are available or not * Can count redemptions, slightly different math. More complexity with metadata and other isser things * Should write down vs let applications discove privacy math * Don't want redemption stuck forever, if issuers can't be switched. * Rotation is complex question * Open questions; protocol vs application, how detailed in the derivation, how much specified about context unlinkability, issuer stickiness. ## Centralization Problem Statement (Mark McFadden, 10 min) * Motivation: Charter milestone. Comes from WG establishment, IABOPEN, plenary * This draft ignores redemption contexts * Potential privacy issues * Problem statement and mitigations * Will be happy to add it * Fundamental issue: limit issuers to avoid client identifier about what they have * Number of tokens at client restricted? Requires limiting at the client, harder than servers. * Arch says max 4 for client to get from * Traditional centralization issue: part of protocol that enforces it. Not network or economic * Architectural, engineering, and deployment issues * Much of this draft talks about what was in the arch draft. * Mitigations (except redemption contexts) don't seem very attractive. Number of issuers vs privacy * Next steps: -01 after IETF ## Open discussion on Issuer consolidation pressure (30 min) * Christian: Problem of anonymity and zero knowledge looks a lot like Oblivious DNS. DNS Oblivious solved with layers of servers. Client auth to first server and then changes tokens out. * Chris Wood: Seems like privacy pass and obvious FO are very different. Anonymous authorization while ODOH and the like aren't about authorization but hiding client identity * Christian: it's the split between client location and the server that's issuing that is common. Because identity is known can correlate, if we hide via second level, then client identity is hidden. * Subodh: Problem could use more formal definition authorization context bound to attributes that might be known and then correlate from making multiple sources. Differential privacy ideas? * Ben (no hats): Want to emphasize issuer cannot link information to redemption. Concern is number of issuers marking a client. Focus on K from Stevens presentation. In applications Ben's aware of goal is user is not a bot. Don't like formulation think it's useful shorthand. In that case a number of trusted issuers being small should be enough. If redemption context can only get one possible token. That math would say a million issuers. Would go a long way to addressing. Wondering if its more. * Kirsty Paine: Issue forever, glad being solve. Anonymity set size, even 5000 is pretty difficult. Is this at enough? Fundamental issue that it might not give much privacy. Substantial piece of work. Not simple solution. Too difficult to resolve. Might be separate issue, and then merge in. Lots of solutions with variation. 5,000 arbitrary, but whole discussion. * Ben (with hat): Chartered to describe risk and ramification and mitigations * Watson: Weakest link makes you get through. Incentive to be small * Steven: Sites will want their issuer, best signal. Not clear all can be swapped. K>1 likely * Richard Barnes: Hard problem. Usual reaction is not work on them. Can we do this here? Huge amount of complexity by having very open interop, while most case very tight redemption issuance context. Even with that not central: Cookies specific to site, but still decentralized. Can avoid by tightness. Didn't see charter requirement for flexibility, am a bit of a tourist. * Chris Wood: Could instantiate many ways. Core of protocol spec is basically unaffected. Do we want to change that such that protocol constrains decoupling issuing and redemption? If so how, if not higher level concern should talk about and document and maybe only focus on demployments with matching. What tangible thing to do to accept richard's proposal or not? * Martin Thompson: Sounds tempting think about point Watson made and reminded of cases where Bot Detection run by third party. Token issued on other site maybe via iframe. Still one entity consuming. Framing seems a bit wrong. RP becomes issuer. Concern is with lock-in. Increased transfer between context. K=2 not that worse than K=1 * Chelsea Komlo: issuer cardinality via multiparty signature schemes. Have a draft. Transfers to issuers * Kirsty Paine: Risk assessment listed with multiple design options. What would it include? Reasonable anonymity set. * Richard; flexibility different from centralization. Comes up in application contexts ---------- # Practitioner feedback on Privacy Pass use cases (Sofía Celi, 15 min) * RWC anonymous credentials meeting * Many unanswered questions due to size * Tor, Google, FB, hCaptcha, Brave, IETF WG * Private/public metadata * Hoarding attacks * Double spending arch messy * Distributed consensus how? * Much reuse? * Goes down * Key rotation * How do we see attacks in practice? * Path forward: practical considerations that people think are misisng, accessibility * How do all these proposals related? SoKs paper * Feedback on problems * Attacks * Novel applications ------------- # Key Consistency Draft (Chris Wood, 15 min) * Problem: Get a key, be sure it's authentic * E.g. privacy pass, tor, OHTTP * Requirements: unlikeable and authentic * N clients, Server with pk, server delivers key to one of them. Gets it later * Partitioning attack! * Authenticity: ensure adversary cannot change the key published by the server * Ideally all clients consistent and correct * KCCS: key consistency and correctness system * Vary over * Threat model * Crypto * PKI * Operational pain * Dependencies * Trusted proxies, outsource * Correctness: digital signatures, other things * Trusted proxy discovery: proxy sends on the key * Client anonymity because server doesn't know who got it * Multiproxy discovery: try it again a few times different proxy each time * Edge case in rotation between queries: not malicious just unluky * External db: append only database like CT, clients get proof, output of consensus protocol, etc. * Currently not meant to be published, lots of variation in what works * Place to start discussion of tradeoffs and variant * How can it help build solutions? * We're not recommending any particular thing ---------------- # Open discussion on next steps for Privacy Pass (15 min) * Christian: Anyone interested in study of economics? Flow of revenues that sustain the provision of these things * Kirsty Paine: Interesting angle * Alex: We don't have a really good solution. Wil have to read Marks draft. In terms of building generic specification for redemption contexts to arch good to hear more feedback. * Mark: more conversation on redemption contexts * Martin Thompson: Cardinality is the real question in the context. We've talkd about private info bit and public data, combine with outhers gets interesting. More analysis required to get numbers. * Chris: What specific things for redemption context not protocol? * Martin Thompson: At 4:30 am not sure I can turn into words. Direction Steven outlined in the arch document. Had imagined in web context is any given website nominates set of issuers that can issue and redeem on website. Browser enforce limit on third party listings. Bot detection, ad fraud, small number of use cases in bucket. Browser polices size of bucket. Site frames in and invokes API. Other origins would be blocked. * Chris: Seems reasonable. * Richard barnes: In a scheme like that where redeemer states issuers redeermer can also state public keys to clear up key consistency * Steven Valdez: In terms of actual things, updating arch doc and API to take in implementing this in the web would get alignment. * Alex Davidson: Moving to architecture permenant proxied verifier state. Always sending tokens to entities to redeem. Right now multiple redemptions. In arch not direct client to issuer redemption. * Martin Thompson: In web context site isn't consuming the token. More likely they have frame or scripts for the third party that issues or redeems. More a case of issuer is redeemer. * Ekr: kinetic set of issuers to every client * Martin: would have to think more. Doesn't matter. Either site can identify or nothing else? * David van Cleve: EKR, can you repeat question? Issuer unique by client? * EKR: root of problem is verifying keys in play. Client view vs. global * Steven: If the site is able to identify the client then issuer choice ahead of time. Different sites aren't able to come * Watson: I understood propposal to be can only interact with a decleared set. Change it, and existed tokens can't be read * Joseph Salowey: hope drafts advance. -------------------- # Metadata (Chris Wood) * VOPRF: no metadata * PMBToken: single bit * PrivateStates, AT with Public metadata arbitrary public data * tokens = F(C priv, C pub, S priv, S pub) * Less than 32 bits please! * Don't want to constrain from new schemes * Was just single round * Now commit phase ahead of exchange. May be skipped depending on scheme * Client puts metadata in the request step * Server has several places to apply metadata in these flows * Unclear where and how we want to accomodate, different possibilities exist * Should API support client metadata that is unbounded * Protocol or crypto put in limits? * Guidance on metadata limits * Chairs: Small amount of metadata in charter * Suboud: Metadata constructed by applications, constraining requires mapping from strings to the bits to be crammed in vs application strings as metadata * Suboud: constrain to 3 or 4 bits doesn't mean only one person has leaked that one bit. Anonymity set size understandable. Hard problem to draw line generically * Ben Schwartz: Additional round trip just for this? * Chris: can be skippable * Ben Schwartz: Load on server from this? And is there a lot of uniformity? * Chris: Don't think so. In private stats can fold into key or real time issueance. Client could provide arbitrary long to fold in. Hash to scalar. * Subod: Wouldn't want to get metadata unacceptable to server * Joe Salowey: better understanding of length or number of options affects privacy * Chris: Every bit halves anonymity set. Don't think privacy calculus accomodates metadata * Martin Thomposon: number of bits combined according to attackers pleasure to be reidentifying. Complete control. 10 bits across three issuers is done. * Chris wood: agree, question is where we do it. * Very general right now, can be restricted * MT: don't want to see unbounded. Potentally put metadata in that isn't server data. Concern is info beyond the server provided. * Subodh: Client understandable vs. client opaque * Size might be different for each ------------------- # Closing * Joe: Hope people update drafts and incorporate this discussion