IETF 108 - Privacy Pass
14:10-15:50 UTC - Friday July 31, 2020
Meetecho Link (Session Audio and Video)
Administrivia (5 Min)
A. Note Well
B. Blue Sheets
b. Scribe: Chris Wood
C. Jabber Scribe:
D. Meetecho
Privacy Pass: The Protocol (30 Min)
draft-davidson-pp-protocol-01
Privacy Pass: Architectural Framework (30 Min)
draft-davidson-pp-architecture-01
Privacy Pass: HTTP API (30 Min)
draft-svaldez-pp-http-api-01
Agenda bash: question about why architecture comes before protocol.
Armando Faz-Hernández - Cloudflare.
Ben Schwartz (chair hat off): It would be helpful to avoid describing this as extensible, and instead present it with the understanding that change control is a WG decision. Don’t think of this as a protocol with extension, but more of a protocol that can change after adoption.
Alex Davidson: The core protocol will have a set of cipher suites and extensions would add extra cipher suites to that. The extensions wouldn’t interefere with the API or message flow.
Ben: WG has not committed to using the VOPRF construction, so any instantiation could be seen as an extension of the protocol.
Steven Valdez: Extensibility here refers to the ability to pass over change control, not to whatever future extensiblity mechanism(s) the WG might bake into the protocol.
Ben: Let’s not speculate too much about what might be in the core protocol and what might be an extension. That’s TBD.
(From chat: perhaps calling this “generality” rather than “extensibility” might be better.)
Alex Davidson - Cloudflare
Ben: Server centralization is mentioned – should that be issuer?
Alex: Server and issuer are identical. Wanted to distinguish between party issuing and verifying tokens.
Mark McFadden: Mitigating centralization can be a separate document. Would like to see that move forward with the other documents. Am willing to work on this.
Steven: How we deal with centralization and registries is somewhat use case dependent. The architecture document is meant to give guidelines for what should be considered across these use cases. A registry is a lot of overhead when not needed by a use case. To what extent the privacy pass document wants to support other use cases is an open question.
Alex: Exactly – architecture document is high level guidelines.
Robin Wilton: Need to differentiate between different parties (e.g. token issuing and redemption server). For example, token minting server for some attribute might not be the authoritative source for that attribute. This should be clarified in the architecture.
Alex: Document could incorporate and clarify these relationships.
Richard Barnes: (Relaying for Chelsea) if you have an anonymity network you could detect malicious key registries by checking from multiple vantage points. If you don’t have Tor, then you have identifiers such as IP addresses. Should we clarify other assumptions about the environment that might help us simplify the protocol or architecture?
Alex: True that Privacy Pass doesn’t help remove other identifiers (IP addresses). We should make that more clear. On Tor, is the idea that clients fetch keys over Tor?
Richard: If you can fetch keys and also check for malice at the same time, you might not need to build in additional auditing mechanisms.
Steven Valdez
(no questions)
Alex: We need more opinions on the key management story.
Bron Gondwana: What are the intended use cases?
Steven: Some base use cases are “is human” bits.
Ben Kaduk: These are intended to be single-use tokens.
Bron: Privacy feature may be harmful in the case of spam (not being able to track where tokens come from).
Steven: Limiting how tokens are issued may mitigate this. Malicious actors would need to register many accounts, for example, to avoid detection and still suceed.
Bron: Unclear about added value, especially when you consider bad actors.
Alex: Tokens are privacy preserving, and act like cross-domain cookies in a way. Lots of good questions around centralization and privacy.
Bron: Look forward to seeing how this plays out and how clients choose to use tokens (or not).
Jonathan Hoyland: Does there need to be a secondary organization (similar to CABF) and ecosystem for maintaining the registry?
Steven: Similar to CABF, though we hopefully won’t have hundreds of issuers for given use cases.
Ben: If use in proof-of-work scheme, the issuer can adjust the work threshold to deter spammers. There are also closed-universe use cases for Privacy Pass, where there are a finite number of token holders and each is rate limited independently. Redeemers can limit the quota per token to ensure that the total capacity of all tokens is within the limit that they’re capable of producing/serving. The system can work to ensure that things work within the limits.
Chris Lemmons: Multiple verifiers can verify tokens, but to prevent double spending, does this require verifiers to coordinate? How do we do this without creating a single point of failure?
Alex: There’s no global double spend check (as of now) – it’s concentrated to a single verifier.
Chris: Double-spend is a “weak” protection?
Alex: Exactly. One of the reasons we don’t require this (and only recommend it) is that we want to keep verifiers independent.
Chris: We need to make sure that verification systems are resistant to attackers creating and spending tokens to fill up double spend buffers.
Alex: Tokens are only valid for the given key they’re issued under. Servers should clear double spend buffers upon key rotation, which is one reason we want to allow relatively frequent rotations. We could also use bloom filters to mitigate against this, for example.
(End of session)