PRIVACY PASS

Administrivia

Implementation Experience

Tommy presenting various deployments:
Two GitHub implementations.
Deployment experience from non-open source implementations.
Shown at WWDC22, Captcha replacement, aiming to increase awareness of
privacy pass.
Cloudflare and Fastly provide issuers.

Based on early betas 35K tokens issued per day.

Nick Dotty: Have you considered the problem of over reliance? What do we
do to make developers not expect get this all the time?
Tommy Pauly: We should give advice about this in the document. This can
be enabled manually by the user. Could be useful to have it randomly not
be performed some of the time.

Core Document Status

Presented by Tommy Pauly

Pretty mature from techical perspective. Getting closer to last call.

Tommy presenting recent changes to the documents.

Open Issues

143 - New registires defined by the documents.
Where does this go? "PRivacy Pass Parameters" page
What review policy? "Specification reqired"

Chris Wood:
Seems fine, can we specify required certain properties for the registry.

Tommy Pauly: Right advice to experts needs to be specified

David Schinazi: How is this encoded, varints?

Tommy Pauly: 16 bit fields.

David Schinazi: Varints allows for a lot more experimentation without
specification required.

Tommy Pauly: Reserve experimental values range?

David Schinazi: Provisional allocations.

Tommy Pauly: Provisional allocations is compatible with "specification
required"

David Schinazi: Do like quic, some of the space is "specification
requruired" and some does not be

Issue 141 - Attestation Compromise
What does the ecosystem do if the attestation system starts doing the
wrong thing?

Solution is likely deployment specific.

Chris Wood: Nothing specific in mind right now, will likely vary based
on deployment model and the config of different parties. This is an
exceptional event, applications should have a way to deal with it.

Tommy Pauly: If some party does bad things it needs to be untrusted.

Chris Wood: Temporary failures should not lead to permanent untrust.

Questions? WGLC?

Sofia Celi:
Two questions:
1: It seems like it's going to be a last call. Does this depend on the
WGLC CFRG of documents?
2: Entities can be compromised and collude etc. Should there be a more
formal document about the implications of compromised or colluding
entities?

Tommy: The document talks a bit about analysis. Totally fine with
further documents that talk about specific analysis. There are several
deployments where this is relevant.

Rifaat Shekh-Yusef: Elaborate the trust betwen parties of the solution?

Tommy Pauly: Trust dependency between enteties - transitive trust and
credibility chain between attesters and issuers .. ?

Chris Wood:
We do not need to block on having gone throuhg all the process in CFRG
to move forward here. We expect implementers to implement properly. We
assume that they follow the specified behavior.

Rate Limited Token Issuance

Presented by Chris Wood.
Update on document presented last time. Adoption call ongoing.

High level overview.
Presenting redemption and issuance protocols.

Problem: Basic issuance protocol does not allow per-client
rate-limiting.
There is no concept of state in the issuance flow.
Rate limiting is useful for several things. Can we add support without
compromising privacy?

Chris presenting how rate limiting typically works in practice.

Rate limiting design constraints:
Origin should only learn that that the does not exceed the rate limit.
Origin adoption should be as simple as basic privacy pass.
Issuance should be as stateless as possible.
Client origin pairs should not be linked by issuer or attesters.

Extends basic issuance protocol:
Issuers associate origin with challenge.
Attester learn stable mapping between per-client and per-origin secret,
without learning per-origin information.

Presents some example diagrams.

Attester state increases, per-origin state per client.

Privacy properties: Attester learns stable mapping between client and
origin secrets.

Two interoperable implementations. Security analysis done, did not
capture origin swapping issue (issue: xx)

Jonathan: Is this an ??.. attack? Client spoofing
Chris Wood: Assumption is that attestation ensures that this does not
happen. The protocol assumes that the client attester relationship
prevents this from happening.

Mirja Kühlewind: Have you considered reversing the rate limiting.

Chris Wood: This was considered in previous version of the document, but
would leak more information.

Nick Doty: Have we established that this metering will be effective for
all use cases, e.g. anti-abuse will a single threshold be sufficent?

Chris Wood: No immideate answer to you.
Tommy: We can't know how everything plays out. Anti-fraud community,
there are origins for which this improves things compared to basic
privacy pass, dosen't provide solutions for the full set of problems.

Benjamin Schwartz: This document is currently undeer an open adoption
call, please provide your feedback to the list.

Key Consistence and Discovery

Presented by Chris Wood.

Motivation:
Many protocols coming up that require clients to discover public keys.
Privacy Pass, OHTTP, Tor.
Common requirements -
Unlikability - Server cannot link key to specific user.
Authenticity.

Every server has a consistent view of these properties and this view is
correct.

Different approaches with different tradeoffs.
Single trusted proxy, multiple less trusted proxies, external database
(bulletin board).

Propose to adopt as informational draft to complement deployed solutions
and proposed specs. Helps inform the discussion.

Tommy Pauly: This is clearly very important. Don't know which WG it
belongs to, does not matter that much either.
Could the approach of double check be described more explcitily?
We could talk about techniques here and let other protocols select
techniques.

Chris Wood: Sounds like a good idea, could be done in various ways.

Benjamin Schwartz: The authors have requested and adoption call, the
chairs will consider that. An announcement can be made at the list,
please review the document and be ready to comment.