# PrivacyPass at IETF 115 Meeting Notes   {#privacypass-at-ietf-115-meeting-notes}

Note Taker: Robin Wilton

## Administrivia (5 min)   {#administrivia-5-min}

We need to get good reviews of core documents, please get your reviews
in.

Tommy Pauly: We got some good reviews on the auth scheme. Would like
some reviews on the issuance protocol.

Joe Salowey (WG Chair): If you've read the docs and you think they're
ready to move forward please comment on the list.

Key Consistency draft removed from agenda.

## Status update on [draft-privacypass-rate-limit-tokens][1]   {#status-update-on-draft-privacypass-rate-limit-tokens}

Slides:
https://datatracker.ietf.org/meeting/115/materials/slides-115-privacypass-rate-limited-issuance-00

*Tommy Pauly (TP)*

Rate Limited Tokens - extension to basic issuance protocol. Based on
publicly issuably variant. This is always done in the split attester and
issuer model. Attester needs to maintain some state on behalf of the
client. Issuer provides rate limit to enforce when token is issued.
Attester drops request if rate limit is reached.

Minor changes to issuance and challenge protocols to enable the rate
limiting. Rate limited token request adds a HPKE-protected request to
the issuer and a signature with a blinded key pair to validate origin
uniqueness.

### Issues   {#issues}

Issue 6 - linkability with malicious issuer. Malicious issuer uses
issuer origin secret across different origins. Based on current text
when an attester detects a collision the token request is immediately
dropped. The problem is that this can act as a signal of what's going
on. Not a huge privacy leak but a bit of information.

Proposed fix: Attesters shouldn't silently drop requests due to mapping
collision. This is a potential information leak and it also doesn't
penalise malicious clients. Instead attesters should flag collisions to
re-evaluate trust in clients or issuers. With non-malicious
implementations you should never have these collisions, so having a
collision does indicate something bad is going on. E.g. Attester could
choose to remove an issuer as a trusted partner if this was happening
across many different clients. Or if it was just happening with one
client the issuer could be removed as a trusted client.

Sidebar: document needs more on how the attester trusts an issuer e.g.
what does an attester need to validate, what are acceptable rate limits,
number of origins to create anonymity set.

Alternative fix for issue 6: Zero-Knowledge Proof that the client
presents to both the attester and the issuer. This relies on crypto that
isn't specified yet. More impact on the protocol than fix above.  
Recommendation of the authors: for basic rate limited type do the simple
fix (flagging collisions) and have ZKP solution as a future token type.

John Bradley: The JOSE working group is in the process of being
rechartered by the IESG to formalise JWP which is exactly what you were
just talking about (JSON token ZKPs).

Richard Barnes: +1 to skipping the addition of ZKP, which looks like a
big change. \[...\] For clarity, I don't think the JOSE ZKP work is
producing fully general ZKP, but it might be enough ot address what
PrivacyPass needs.

Jonathan Hoyland: I don't object to skipping it, but the concept seems
worth exploring.

Steven Valdez: It's not a massive change to the core PrivacyPass
protocol itself, but would need an extension to the crypto.

Jonathan Hoyland: How does Sybil protection work?  
Nikita Borisov: AIUI, the attester verifies client identity and is
responsible for Sybil protection.

TP: Other open issues:

*   Issue 1 - One bit token key ID
*   Issue 2 - Hiding issuer rate limit from the attester (authors think
    this would work better in a future token type.)
*   Issue 5 - More discussion around rate limiting tokens with
    origin\_info with multiple origins.
*   Issue 8 - Clarifying trust relationship between attesters and
    issuers (see sidebar above)

Next step is to update the document based on issues discussed here.
Still tracking CFRG dependency of signature key blinding.

Nick Doty: Does the origin choose a singular issuer and give the client
a particular key to use to encapsulate a request? Seems like a potential
tracking vector. Is the assumption that there should be a single key for
each origin?  
Tommy Pauly: Some overlap here with the Key Consistency ID's approach.
There would be one "slowly rotating" key for a given issuer. Working
with the attester is one way to achieve that.  
ND: In that case, does the key even need to come from the origin?  
TP: No, it's optional. Origins include e.g. RSA client sig public key
they're going to use. That therefore doesn't need to be in the
PrivacyPass protocol's challenge, if the client has another way to get
it.

Ben Schwartz: Is the "blinding" mechanism here actually equivalent to
taking the public key and encrypting under symmetric encryption?  
Steven Valdez: It's more complicated than that. It's using the public
key update issuer but there's some extra blinding. If we didn't care
about the origin learning ?? we could do something simpler but we need
the key blinding here.  
Ben Schwartz: Can take this up offline.  
TP: Would rather that Chris Wood or other authors commented on that.

Joe Salowey: Sounds like we have a way forward. Expect to see some
revisions over the next couple of months.

## Status of relevant work in the W3C   {#status-of-relevant-work-in-the-w3c}

*Steven Valdez*

Slides:
https://datatracker.ietf.org/meeting/115/materials/slides-115-privacypass-slides-115-privacypass-w3c-00

There is relevant work in W3C:

*   Private Access Tokens
*   Private State Tokens
*   Device Attestation
*   Other (PATCG, Privacy CG, WebAuthN/Web Payments) \[CG = W3C
    Community Group\]

How much of this do we want to pursue in the PrivacyPass Group?

Private Access Tokens - Quite mature. Very similar to what's going on in
Privacy Pass, specifically the Blind RSA version of the protocol and
rate-limited tokens. There are some API changes to hook into/understand
responses to do with Private Access Tokens. Currently not in a
particular group.

In W3C there are interest groups where there are different types of
groups. Privacy Pass work will probably end up in web ? group, but there
might be some stuff that belongs in a new group.

Private Access Tokens - Token issuance via a trusted attester/platform.
In Apple case this is the Apple platform. Then any origin can redeem
tokens. Rate limiting is important, token farming is quite common in the
web space.

Private State Tokens - Previously known as Trust Tokens. Based on an old
version of Privacy Pass - VOPRF tokens, and a non-standardised version
using PMBTokens. Plan to update this to a newer version of PP. Not clear
how much interest here. PST work is currently in the Web Incubation
Community Group (WICG) - might migrate to the Antifraud CG because
that's the core use case for this API. Any website can issue tokens.
Other origins can redeem tokens. Needs to be relationship between
issuers and redeemers to share understanding of what the tokens are for.
Minor different to Privacy Pass - concept of redemption context, stored
local cache version of redemption per top-level (e.g. per page, to avoid
having dozens of tokens for a single page. There are some other deltas
between PSTs and Privacy Pass but it's hopeful these will go away as the
work progresses (see slide 8 for details).

Device Attestation - Slightly less fleshed out. This has come up in W3C
anti-fraud group. Way to attest to facts about device or client. Needs a
mechanism to do this without leaking information about device ID.
Something privacy pass-esque might be good here, potentially building on
PATs or PSTs, or maybe something else.

Other uses:

*   PATCG Private Advertising Technology CG: considering an aggregate
    reporting API to allow misbehaving devices to be reported; still
    needs PrivacyPass-like privacy/unlinkability features.
*   Privacy CG - Looking at other types of Privacy Preserving
    Technologies.
*   WebAuthN/Web Payments - Had a meeting with the Anti-Fraud group,
    Privacy Pass might be helpful for some of their problems.

Martin Thomson: This might be misrepresenting a bit what PATCG is
working on. Some designs don't require anything like Privacy Pass, some
do.  
SV: These are places where something like Privacy Pass has come up,
might be helpful.

Joe Salowey: There are connections, are there any problems we need to
address or any expectations from W3C?  
SV: It's in early days so nothing major yet. For some things,
particularly key consistency, it might be useful to have some baseline
information in the IETF.

Ben Schwartz: Sounds like W3C work is nascent. None of these proposals
have moved into a WG. What are the odds that by the time this is moved
into a WG the specs we're writing now aren't what's needed?  
SV: That's one of the benefits of how the protocol models are
structured. If we need new properties we can design new token types.
Core protocol structure is what we need.  
Tommy Pauly: HTTP-Auth scheme is usable by various websites without a
change to JS APIs or the need for W3C to adopt it. W3C is not our only
customer, people can benefit independently. There is probably some
minimal work to be done in W3C that would integrate well with what we're
defining in Privacy Pass (e.g. to allow specification per iframe of
which elements are allowed to request challenges). There are other use
cases that may be able to use Privacy Pass as we're designing it, or may
need new token types.

Nick Doty: Is there documentation on Private Access Tokens?  
TP: Private Access Token name is not a formal thing, it's what marketing
at Apple wanted to call it. Really all it is is a basic, publicly
verifiable Privacy Pass token. We also intend to support type 3 and
other attesters and platforms can support them as well. The question is
do we have changes to fetch or permissions policy saying what resources
are allowed to include privacy pass auth scheme challenge?  
ND: Is there a dependency on or adoption of newly adopted rate limited
tokens?  
TP: It's a bit separate. Type 2 is supported in production with us with
different issuers. We support beta testing with rate limited version.
Type doesn't impact permissions policy in W3C. View this more as a way
to enable communication about Privacy Pass in the permissions policy.

## Next steps for Privacy Pass   {#next-steps-for-privacy-pass}

*Chairs*

Ben Schwartz: Want to ask the WG where they think this work should be
going.

Where we are:

*   Arch document completed last call - holding.
*   Issuance and HTTP Authentication Scheme Documents in WGLC - if
    you're familiar with them please tell us that you think they're in
    good shape.
*   Key Consistency recently adopted, no major changes in flight
*   Rate Limits adopted, still evolving - lots of attention.

What else do we want to work on?

*   Consolidation considerations?
*   Additional token types or issuance flows (e.g. batch token issuance
    flow)?
*   Consistency protocols? Ben has a draft...
*   Attestation?

What topics does the WG think are interesting and consistent with the
Charter?

MT: In the consistency space we need a good definition of consistency.
There has been some discussion about the exact shape of consistency
protocols - e.g Richard Barnes' comments about producing something like
"CT without all of the warts". That discussion should happen here. I
don't know that we're in a good position here to make a strong decision
about the exact nature of those protocols.

SV: In W3C we're flying by the seat of our pants with regards to
consistency. Would be nice to have something standardised. Chris's draft
is a good start, but we need more.

SV: As a new token type there might be some interesting work coming out
of the ZKP extension mentioned in Tommy's presentation. (cf. Issue #6)

BS: Formal verification might be interesting, we don't have any formal
verification of the cryptographic arrangements we have been specifying:
that might be nice to have.  
TP: Chris Wood might be better to talk about this, but the basic token
types for rate limiting have formal verification, that's how issue 6
came up.  
Nikita Borisov: There is a formal verification of the current protocol
usingProverif, which shows the secutiry properties - other than the
unlinkability issue Tommy discussed. I think there will be publication
soon (in the next month or two).

Philipp Pfeiffenberger: Regarding future work and concerns: currently,
when an attestation mechanism is compromised, any abuse of the mechanism
will impact on Relying Parties, but the attester has no way of homing in
on which devices are compromised - i.e. blinding has some side effects,
in that it may be impossible to block or fix a misbehaving endpoint.   
It's also unclear how issuers can choose attesters, and how relying
parties assess the relative strength of these attesters and issuers.

\[From chat\]:  
Daniel Gillmor: +1 to Philipp for explicitly identifying some core
tensions of this work.

Ben Schwartz: One thing that might be useful is something about the
architecture, how is the privacy pass system used and how could it be
used. What are we expecting defence against, like, can a single origin
"drain" your entire stock of PrivacyPass tokens, or are we expecting
that to be defended against at some upper layer. I'd love to see an
informational draft about that.

Richard Barnes: OHAI has a similar Key Consistency challenge and has
been discussing the issue. More general consistency property for http
resources is desirable, to guarantee that a given client is getting the
same service as other equivalent clients. A more generalisable approach
would be good, without prejudging whether the work would be done here,
in OHAI or elsewhere.

Ben Schwartz: I hope you've been inspired to contribute to the WG. If
you're working on formal analysis it would be great to see the results
of those.



[1]: https://datatracker.ietf.org/doc/draft-ietf-privacypass-rate-limit-tokens/