IETF 111 - Privacy Pass

IETF 111 - Virtual

July 30, 2021, 14:30-15:30 Friday Session II

Note taker: Christopher Patton <cpatton@cloudflare.com>

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.