Markdown Version | Session Recording

Session Date/Time: 11 Nov 2022 12:00

privacypass

Summary

The privacypass working group met to discuss the status of its core documents, review updates to the rate-limited issuance draft, and explore related work in the W3C. Key discussions included a newly identified linkability attack in the rate-limited issuance protocol and its proposed mitigation, the potential for new token types based on zero-knowledge proofs, and the critical need for a standardized key consistency mechanism. The group also considered future work areas, including formal verification write-ups and informational drafts on usage models.

Key Discussion Points

• Core Documents Status

  • The Architecture document has completed working group last call and is being held for joint consideration with issuance and authentication documents during IESG review.
  • The Issuance and HTTP Auth Scheme documents are currently in working group last call. Strong review activity is requested, especially for the issuance protocol.
  • The Key Consistency informational draft was recently adopted, but no presentation was made.
  • The Rate-Limited Issuance document is making good progress.

• Rate-Limited Issuance Document Update

  • Recap: This draft is an extension to the basic issuance protocol, based on the publicly verifiable variant (Type 2). It operates in a split attester/issuer model where the attester maintains state for anonymized origin buckets, counting received tokens. The issuer provides a rate limit to the attester, which drops requests if the limit is reached.
  • Protocol Differences: Uses a different token type, includes an HPKE-encrypted inner request (containing origin name) passed to the issuer via the attester, and features an anonymous origin ID from the client to the attester for counting. Signatures are exchanged to prevent client cheating (making one origin appear as two).
  • Security Issue (GitHub #6): A linkability attack was identified involving a malicious issuer reusing the issuer_origin_secret across different origins. If the attester naively drops requests upon detecting a collision (assuming client cheating), this could leak information, indicating the client previously interacted with a different origin.
  • Proposed Fix: Instead of silently dropping requests, the attester should flag collision events. These patterns should be used to re-evaluate trust in either the issuer (if collisions are widespread) or the client (if singular). The attester should then reject future requests from a misbehaving client or stop using a malicious issuer.
  • Attester-Issuer Trust Relationship: More text is needed in the document to define the trust relationship, including validation criteria for issuer-provided rate limits (e.g., window lengths, rate limit bounds, anonymity set size).
  • Zero-Knowledge Proof (ZKP) Alternative: Nikita suggested using ZKP for client cheating prevention. This would involve new crypto (CFRG work), significantly impact the protocol, and is seen as potentially cool but too large a change for the current basic rate-limited type. It is recommended for consideration in future token types.
  • Other Open Issues: Discussed token key ID length, potential for hiding issuer rate limits from the attester (future work), handling rate limits with multiple origins in origin_info, and expanding the attester-issuer trust relationship text.
  • HPKE Key: The hpke key provided by the origin in a challenge could be a potential tracking vector if not consistently managed. Emphasized consistency, potentially with the help of the attester.

• W3C Related Work Overview (Stephen, Google)

  • Private Access Tokens: Based on blind RSA and the rate-limited token draft. Minimal deltas from existing privacy pass. Requires W3C Fetch API changes and delegation mechanisms. Likely to be discussed in WICG or Anti-Fraud CG.
  • Private State Tokens (formerly Trust Tokens): Based on older vopf and PMB tokens. Plans to update to newer RFCs. Moving to Anti-Fraud CG. Websites (first/third party) issue tokens. Redemption records are used to reduce token spending per page. Uses /.well-known/ for key commitments (needs standardization, related to key consistency). Runs protocol via HTTP headers on existing fetches. Future plans include Fetch JS API and HTTP authentication.
  • Device Attestation: A need for anonymous credential-style mechanisms to attest to device facts without leaking identity.
  • Aggregate Reporting API (Pat CG): Potential use of privacy pass for authenticating client reports without direct user identifiers. May require public metadata features.
  • WebAuthn/Web Payments: Interest in blind signatures/anonymous credentials.
  • Relationship to IETF Work: W3C work is nascent; core privacy pass types are seen as a strong foundation, adaptable for new token types as W3C use cases evolve.

• Future Work Discussion

  • Key Consistency: A strong need exists for a concrete, standardized consistency protocol to ensure privacy guarantees. Discussion is nascent, with ideas like a "CT-like" approach for HTTP resources.
  • Formal Verification: The basic and rate-limited token types have undergone formal verification using ProVerif, which uncovered Issue #6. A public write-up of this verification is expected.
  • Attester Compromise: Concerns were raised about how to identify compromised devices/attesters without violating blinding, and how relying parties assess the strength of attesters/issuers.
  • Usage Models/Informational Draft: An informational draft describing expected privacy pass usage scenarios, potential challenges (e.g., origin draining all tokens), and mitigation strategies could be beneficial.

Decisions and Action Items

• Decision: For the rate-limited issuance protocol, the attester should not silently drop requests upon collision detection. Instead, it should flag collisions and re-evaluate trust in the issuer or client, leading to future rejection of requests for a misbehaving client or untrusting of a malicious issuer.
• Decision: The Zero-Knowledge Proof (ZKP) approach for client cheating prevention, while interesting, should be considered for future token types rather than the current basic rate-limited type due to its reliance on new crypto and significant protocol changes.
• Action Item: Working group members are urged to review and provide comments on the mailing list for the Issuance and HTTP Auth Scheme documents, currently in working group last call.
• Action Item: Authors of the rate-limited issuance document will update the draft to incorporate the proposed fix for Issue #6 and expand text on the attester-issuer trust relationship.
• Action Item: A write-up of the formal verification for the basic and rate-limited privacy pass types will be made public in the coming months.

Next Steps

• Continue refining and advancing the Rate-Limited Issuance document based on identified issues and discussions.
• Track the dependency on CFRG for signature key blinding in the rate-limited document.
• Further discussions and potential work on a concrete Key Consistency protocol.
• Monitor developments in the W3C related to privacy pass and assess potential areas for IETF contributions (e.g., standardizing key commitment discovery).
• Consider exploring new token types, potentially leveraging ZKP, in future work.
• Explore the creation of an informational draft detailing privacy pass usage models and addressing operational concerns.