Privacy Pass Interim January 2022

Note Taker: Matthew Finkel

Agenda: https://datatracker.ietf.org/doc/agenda-interim-2022-privacypass-01-privacypass-01/

Presentation 1:
Architecture (Chris Wood):
  - Going back to drawing board
  - Easy to deploy, satisfying charter requirements
  - Goal: why reframing is more appropriate for PrivacyPass
  - (Presentation describes current PrivacyPass client-server flow)
  - Solving CAPTCHA was original motivation for PrivacyPass
  - PrivacyPass could be an asynchronous proof of solving CAPTCHA
  - PrivacyPass could be generalized for providing any attestation
  - Architecture can separate Issuer and Origin if Origin trusts Issuer
  - Arch can be further divided by responsibilities: Issuer, Attester, Server (origin)
      - Issuer and Attester have a trust relationship
      - Issuer and Server have a trust relationship
(Jana Iyergar takes over presentation)
  - New architecture allows for deployment variations
      - Combined origin/attester/issuer
      - Origin and combined attester/issuer
      - All separate: origin, attester, issuer
  - Variations provides more flexibility for more deployement scenarios and use cases
  - Redeption protocol (between client and origin) can be identical across all variations
  - Issuance protocol varies by use cases
  - Why rework PrivacyPass Arch?
      - Current design tightly couples issuance and redemption
      - Prevents some use cases
      - Makes all parties explicit, while attester was previously implement
  - Questions:
      - (Benjamin Schwartz): What interactions need to be standardized, and which are deployment-specific?
      - Jana/Tommy: Not defining how clients interact with Attester, but defining/standarizing token issuance
 
 Presentation 2:
 Challenge & Redemption (Tommy Pauly)
  - Redemption protocol: server interacts with client where there isn't a previous trust relationship
  - Challenges are optional but usually necessary
  - Previous work in W3C JS API required javascript driving interaction
  - Using HTTP Auth provides a better framework than relying completely on JS
  - Proposal: Replace HTTP API doc
  - Features: IANA token types, supported protocol, origin-vendor trust
  - New protocol/design simplfies deployment by origins and mitigates some existing concerns
  - Proposing new HTTP WWW-Authenicate 'PrivateToken' challenge (see slide example)
      - Redemption is by HTTP Authorization 'PrivateToken'
  - New protocol maintains client unlinkability
  - Must replace HTTP API doc with HTTP auth scheme, update W3C API work
Questions:
 Joseph Salowey: Protocol shape is the same, but interactions change?
 Tommy: Needs for flexibility with public verifiability, but desire to maintain common design
 
 Ben: Timing based linkability concerns. 1) What do you think about concerns that timing may identify user?
 Tommy: May be a concern, but  more mitigated for higher-volume sites. Separated trusted attester may be able to inform client if there is large (or small) anonymity set
 Ben: Token buckets create larger anonymity sets than interactive protocols. Need privacy analysis. Interactive protocols have a less measurable privacy property and anonymity set size
 Ben: And, separately, Is nounce blinded?
 Tommy: yes
 Chris: Client identifiability may be possible after the fact, under some circumstances, but there is some flexibility where the client could delay its responses to mitigate some timing leakage.
 Chris: Offering recommendation is very difficult at this abtract layer
 Tommy: Thinking about separation of attester and issuer is helpful in this scenario, and mitigating timing attacks because issuer and origin may not have enough information about client (e.g., if client is not leaking/revealing other info)
 
Issuance:
 - Origin sends client a challenge with public key and additional info
 - Client does some crypto (nounce, creates context, runs blind sig protocol)
 - Client sends request (using sig) to Issuer (possibly via attester)
 - Client receives response from Issuer, and creates authenticator, sends token to origin
 - Extensible issuance protocol with varying features and target use cases:
     - POPRF
     - RSA Blind Signatures
     - (more proposals mentioned)
     - Multi-round trips are possible but currently excluded at this time due to security deployment concerns
 - Issuer deployment considerations:
     - protocol is stateless on the issuer-side
     - key consistency is out-of-scope of this proposal, but should be handled elsewhere if appropriate
 - Security properties:
     - One-more unforgeability
     - Issuance secrecy
 - Proposal: reorganize protocol document around new issuance protocol details
     - Use token type as the extension mechanism
Questions:
 - Ben: Any thoughts of proposals by current draft authors?
 - Steven Valdez: Generally seems reasonable, but needs some clarification.
 - Alex Davidson: These proposals are clear and make sense. Should be addressed: How do we parameterize the privacy properties?
 - Chris Wood: Support new direction
 - Sofia Celi: Support new direction. Some open questions, but worth adopting.
 - Ben: All comments have been supportive, any opposing views? (none)
 - Ben: Work should continue, and call-for-adoption should happen in the near future
 - Joe: Agreed
 - Tommy: Auth scheme is not an I-D yet, blocked by some open PRs. We'll focus on some of the existing questions of timing issues, if that's most interesting/needed now.
 - David Schinazi: Process question: what's blocking call for adoption.
 - Ben: I-D doesn't exist yet
 - Joe: There's an ordering dependency right now.
 - Chris: We can merge arch changes, and/or move forward with protocol doc updates. Should we start with auth scheme changes? We could abstract out some details, and temporarily remove cyclic dependency between drafts.
 - Jana: Treat redemption and arch docs as a bundle
 - Ben: None of the docs should land until ready for adoption?
 - Jana: See if that's successful, and adjust if needed.
 - Chris: Prefer not going down that route .
 - Joe: Do we have a set of requirements for attestation protocol?
 - Chris: No, deployment specific - keeping out-of-scope
 - Tommy: The doc does/should describe, broadly, what is does
 - Chris: Proposal: Add considerations around timing attacks, publish auth scheme draft, move forward with merging
 - Tommy: Implementations/Interop testing is in progress. Chris has a version that can be tested.
 - Chris: Implementation here: https://github.com/cloudflare/pat-app
 -