Markdown Version | Session Recording

Session Date/Time: 24 Mar 2022 12:00

privacypass

Summary

The privacypass session at IETF 113 focused on updates to the core architecture and authentication scheme drafts, as well as the introduction of a new draft for Rate Limit Tokens. Discussions covered deployment considerations, privacy implications, and specific technical changes to the challenge/response formats. A significant part of the session involved presenting and discussing the proposed Rate Limit Tokens protocol, including its motivation for anonymous fraud prevention and metered paywalls, and a call for working group adoption.

Key Discussion Points

• Core Drafts Update (Architecture and Authentication Scheme)

  • Architecture Draft
    • The latest revision explored deployment considerations and their impact on client privacy.
    • The architecture is split into an issuance protocol (client, attester, issuer) and a simpler redemption protocol (client, origin).
    • Introduced concepts of Redemption Context (origin name, timestamp, client IP, etc., seen by origin) and Attestation Context (timestamp, client IP, metadata, seen by attester).
    • Meaningful privacy is defined as no single entity linking per-client and per-server information across these contexts.
    • Deployment Models:
      • Joint Deployment (Attester = Server): As in current Privacy Pass deployments (e.g., CAPTCHAs). Requires client separation over time (via unlinkable tokens like blind signatures/OPRFs) or space (via proxies/Tor) to achieve meaningful privacy.
      • Split Deployment (Attester != Server): Useful for less privacy-friendly attestation mechanisms (e.g., account ownership). Lowers the privacy bar, as the attester and server do not share context. Attestation must not reveal per-server info, and redemption must not reveal per-client info.
    • Next Steps for Architecture Draft:
      • Address double-spend requirements for cross-origin tokens.
      • Update privacy parameterization based on the current architecture.
      • Address centralization (potentially punt to Mark's draft or integrate his text).
      • Consider working group last call or focus on issuance protocols.
  • Authentication Scheme Draft
    • Newly adopted; 01 version published with minor terminology changes.
    • Terminology Renames:
      • redemption_nonce field in the challenge structure was renamed to redemption_context to better reflect its purpose as a server-chosen context, not necessarily a nonce, for binding tokens.
      • A confusing context name in the token struct (returned to origin) was renamed to challenge_digest, as it is a hash digest of the challenge.
    • Stabilizing Format: Authors seek feedback now to stabilize the challenge and response format for deployment and interop.
    • Challenge Structure (private-token HTTP auth scheme): token_type, issuer_name, redemption_context (optional), origin_name.
    • Redemption Structure: token_type, client_nonce, challenge_hash, token_key_id, and issuance-protocol-specific bytes.
    • Discussion on origin_name: Ted Hardy questioned allowing opaque_origin_name to appear multiple times or represent a list of origins (e.g., for Google/YouTube) to scope tokens more precisely than general cross-origin. Stephen suggested origin_name be an opaque blob whose interpretation is left to the use case.
    • Origin (Server) Behavior: Simple challenge generation, choice of issuer(s) and token type (per/cross-origin). Optional redemption_context helps narrow double-spend prevention state (e.g., client IP hash, session ID).
    • Client Behavior: Manage token caching (reuse, eligibility), clear cached tokens with cookie state, verify origin_name information.
    • Next Steps for Auth Scheme Draft:
      • Address the discussion point regarding the origin_name field.
      • Continue polishing the document and interop testing.

• Rate Limit Tokens Draft

  • Motivation: Rate limiting is crucial for fraud prevention but often relies on privacy-invasive tracking (cookies, IP). Basic Privacy Pass tokens (attesting device legitimacy) are insufficient for cases like click farms or metered paywalls, leading to users still being blocked.
  • Token Buckets: Refreshed understanding of token bucket mechanics for rate limiting (replenish tokens, remove tokens on request, capacity limits).
  • Rate-limited tokens attest to both device legitimacy and that access rate for an origin is below a threshold, mitigating issues like click farms and enabling metered paywalls without user privacy loss.
  • Protocol Overview:
    • Extends basic RSA blind signature issuance protocol.
    • Requires Split Deployment: Attester and Issuer must be separate entities for meaningful privacy.
    • Attester's Role: Sees client identity, maintains a counter, learns a stable mapping between client and anonymized origin identifier (using per-client and per-origin secrets). Does not learn the specific origin.
    • Issuer's Role: Defines the rate limit (e.g., 3 times/hour) and informs the attester during issuance.
    • Core Challenge: Computing the stable mapping (bucket identifier) in a privacy-preserving way so the attester doesn't learn the specific origin, but can still enforce per-client, per-origin rate limits.
    • Uses a "signature scheme with key blinding" (similar to an OPRF) to achieve this.
    • Status: Operable implementations (ECDSA variant) exist. Security analysis is underway.
  • Discussion on Adoption:
    • Ben Schwartz questioned if standard Privacy Pass architecture could achieve similar goals (e.g., a magazine acting as issuer/validator issuing monthly tokens).
    • Authors clarified that Rate Limit Tokens address the anonymous case (e.g., fraud prevention during account creation) where users don't have existing accounts with the origin.
    • They highlighted the challenge of avoiding an issuer learning client browsing history if it maintains per-origin state for multiple services. The goal is to shard state and push accountability to an origin-funded entity, preventing a central attester from accumulating unbounded state or linking client activity across multiple origins.
    • Authors acknowledged that earlier, simpler designs compromised privacy (revealed origin info to attester) and encouraged suggestions for simpler solutions that maintain desired functional and privacy properties.

Decisions and Action Items

• Architecture Draft:
  • Action: Address the open issue regarding double-spend requirements for cross-origin tokens.
  • Action: Update privacy parameterization within the draft.
  • Action: Discuss how to address the centralization issue, either by punting to Mark's separate draft or integrating his text into the architecture document.
• Authentication Scheme Draft:
  • Action: Address the discussion point on how to best handle the origin_name field, particularly for scenarios involving multiple related origins or opaque definitions.
  • Action: Continue polishing the document and conducting interop testing.
• Rate Limit Tokens Draft:
  • Decision (Pending): The working group will continue discussion on the mailing list to determine interest in adopting this draft.
  • Action: Authors encourage the community to propose simpler architectural solutions that maintain the desired functional and privacy properties.

Next Steps

• Continue discussions on the privacypass mailing list regarding the adoption of the Rate Limit Tokens draft and potential alternative designs.
• Consider scheduling an interim meeting to discuss the Rate Limit Tokens draft and the consolidation of various issues across the core drafts.
• Authors of the core drafts will proceed with the identified action items, aiming towards potential working group last call for the architecture document once key issues are resolved.
• Authors of the Authentication Scheme draft will continue polishing the document and collaborating on interop testing.