# IETF 111 - Privacy Pass IETF 111 - Virtual July 30, 2021, 14:30-15:30 Friday Session II Note taker: Christopher Patton ## Document Updates Presenter: Steven Valdez Reminder that spec is split into a few drafts: * architecture * ecosystem * crypto primitives * API Closed issues * 66: Add redemption contexts * 68: RFC8446 Vector Syntax Open issues * 67: Refactor redemption flow * (arch) 2: Identifying malicious servers * (arch) 44: Redewmption mode in public config * (arch) 45: Centralization documentation * (arch) 46: Expose of token in proxied-verifier * (arch) 65: Update privacy calculation * 40: Public verifiability * 42: Private metadata bit variants * 63: client and server metadata * 77: Pin protocol messages to crypto scheme PRs * 79: Supporting other constructions Open questions * (1) Refactor docs to abstract protocol for additional constructions? * (2) Update charter timeline * (3) Metadata support in the draft? ### Discussion * Benjamin Kaduk: To question (1), there's always the risk of getting the abstractions wrong. * Chris W.: Point of PR is that the current abstraction is wrong. * Ben Schwartz (no-chair hat) / Chris W.: No new document for proposal; it does depend on a CFRG document. * Ben Schwartz (chair hat): Alternative to Chris W.'s proposal? **None given.** Charter timeline updates? **No feedback from the room.** ## Adding public metadata Presenter: Sofia Celi github.com/ietf-wg-privacypass/base-drafts/pull/78 * Proposal is based on ePrint 2021/864 * Other proposals: * "Private metadata" 2020/072 * "Attribute-based VOPRFS" (Facebook) * Metadata is useful for "Hoarding attacks" (not addresed by base protocol) * Malicious user(s) want to DoS the service * Useful metadta: * "Epoch" (linked to key rotation) * Geographic localization * Based on VOPRF "with PO-PRF" (new primitive introduced in the paper) * The only change for Privacy Pass is the introduciont of metadata. * Additional security considerations * Metadata diminishes anonymity set. * PO-PRF doesn't have a theoretical bound on metadata length, but applications SHOULD bound it somehow. (Trade-off between privacy and utility.) ### Discussion * Chris W.: This is a good idea. Question: Should all implementations support metadata? * Steven Valdez: Requiring metadata for every impl is too high of a bar. * Sofia: We're considering this in the CFRG draft. * Joseph Salowey: Maybe we just accommadate the current use cases and not make it generic. * Chris W.: Leave it up to the application. * Alex Davidson: Does PO-PRF support *no* metadata? Could this construction be used instead of the original VOPRF? * Sofia: They have basically the same performance, so yes. * Ben Schwartz (no-chair hat): Trade-offs between public metadata vs having a larger number of issuer keys? * Sofia: Needs analysis. * Steven Valdez: Ben's strawman is fine if you just have a few bits of metadata. * Chris P.: Use cases with more than a few bits of metadata? * Sofia: Not yet. * Ben Schwartz (chair hat): What's your recommendation? * Sofia: **Yes, but let's get some feedback from CFRG about adding PO-PRF to existing VOPRF draft.** ## Summary from 2nd anonymous credentials meeting Presenter: Steven Valdez Recap of meeting at PETS '21. * Presentations * Lattice-based VOPRF (eprint 2019/1271) * More metadata [missed eprint report number] * Contact tracing use case (eprint 2021/203) * Anonymous credentials meetings happen about twice a year (next one is around RWC '22) ### Discussion * Joseph Salowey: Does metadata solve any use case discussed at PETS? * Steven V.: Some, yes. Metadata doesn't solve time-bound tokens (need a new construction). ## Post-Agenda * Benjamin Kaduk: Why not dump VOPRF and adopt PO-PRF? * Chris W.: What is the difference a protocol that is a partially blind signature and Privacy Pass? * Alex Davidson: There are applications where symmetric VOPRF is going to be better than PO-PRF. * MT: It seemed to me (in the jabber chat) that VOPRF isn't any better. But I'm coming around to the idea that having a choice might be good. * Ben Schwartz (no-chair hat): Which constructions make the weakest assumptions? * Alex D.: * Original VOPRF is based on one-more-gap DH * PO-PRF is based on another fancy DH assumption * Blind RSA is based on RSA * Pairings-based schemes are based on ??? * MT: We've got a zoo of primitives, all with different capabilities. None achieves all of the security/efficiency properties of all of them. This is worrisome. * Chris W.: Not all applications need to have the same security properties, but there should be some baseline security property that they all provide for Privacy Pass. * Sofia: +1 to Chris W. * MT: When we do engineering, we pick a tool that works for the use cases we have. What it sounds like we're doing is trying to support all use cases.