IETF 111 - Privacy Pass
IETF 111 - Virtual
July 30, 2021, 14:30-15:30 Friday Session II
Note taker: Christopher Patton firstname.lastname@example.org
Presenter: Steven Valdez
Reminder that spec is split into a few drafts:
- crypto primitives
- 66: Add redemption contexts
- 68: RFC8446 Vector Syntax
- 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
- 79: Supporting other constructions
- (1) Refactor docs to abstract protocol for additional constructions?
- (2) Update charter timeline
- (3) Metadata support in the draft?
- 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.
Presenter: Sofia Celi
- 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.)
- 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.
- 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)
- 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).
- 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.