Current Summary:
Core docs in RFC editor
Batch tokens in last call
Update on adopted draft
Client Fetching patterns and authenticity issue discussion
Binary HTTP issue
Should we validate only specific header fields or the entire response?
Martin Thomson: Just a head request could be sufficient. Confirm with
hash
Issue: Config rotation:
Cache resource across responses.
How does client handle inconsistency when mirror and resource are out of
sync
Mention best practices for this
Lifetime doesn't mean how long its getting served and there can be
overlapping lifetimes.
Ben Schwartz: there is no consistency in this case. e.g. different
versions in different caches
Martin: Allow for the possibility of config and resource change. A bunch
of caches for the purpose consistency check will be outdated and client
will find it to be outdated.
There could be mirrors and more than one could be used to solve the
problem.
Steven:
Even if we don't allow overlapping , there will still be these sorts of
problems.
With a lifetime, you have committed to that resource for that amount of
time and no guarantees when you change it before that
Steven: Enough Sharp edges to worth dealing with in the draft
ISSUE: Thundering herd at expiriation
If resource expires, theres many clients at the same time at the mirror
when all they need is another consistency check
Traffic patterns experienced by the mirrors need to be thought out.
If you have the resource commit for the hour, you have guaranteed
thundering. Make sure not to create sync mechanisms and what was
discussed in the previous issue might cause it
Client IP leakage when mirror is accessed
Don't actually need to solve it, suggestions in draft
Adoption call issue: Client fetching patterns
Document calls out on consistency not authenticity
Require additional fetch for some cases.
Martin: Draft talks about the second request but not the first one, so
this issue was filed to request that
Other issues: if they become larger issues, they will be brought to the
WG
Next steps: resolve open issues.
Anyone interested in implementations?
Ben Schwartz:
We need to reach clarity on whether it is permissible for origin to have
outstanding inconsistent copies of resource. This needs to be carefully
thought and agreed to in teh draft.
Discussion for rate limiting on the list.
Review of bunch of drafts and suggestions for future area of works
Two adopted drafts in privacypass
auth scheme extensions:
Spot for us to send extensions in privacy pass
Metadata
privately and publicly verifiable metadata
Metadata can open up identifying issue of clients if they're not careful
More privacy discussion
Test vectors for variants of crypto in the draft. Please look at the
draft
Example of Chrome IP Protection
Expiration extensions and what they plan to using
IP Protection is proxying subset of requests in the Chrome browser
An auth mechanism for clients
uses MASQUE
uses two proxies Proxy A and B. Both authenticated by privacy pass
The metadata is in the tokens used to authentication
Expiration for tokens
Geo for user
Servtice type
Debug mode (for devs)
Proxy Layer: which proxy is this token for
You add too many bits or add specific geo, you lose privacy
geo can't be "my home address".
If there are many users in the geo, then its better. Example NYC metro
as a whole as a geo hint
Geo is the biggest concern for privacy
will have a well known set of geos
Timestamps: ways to round the expiration so there will be many users in
that expiration timing to not get identified
Some tokens valid for less than others and are changed dynamically.
Gives flexibility.
Two drafts adopted so far, neither are extensions
Give us feedback on draft.
Expiration timestamp decouples token expiration with key.
Clients can cache tokens.
Deploy dynamically adjusted timestamps due to constraints
Please look at the expiration draft
Next steps:
iterate on drafts
Adopt expiration extension and other custom ones
Request CFRG for adoption call for partially blind RSA
Steven:
Expiration makes sense here for metadata, tokens etc. Theres a lot of
things here and aligning all of them seems complicated and maybe have a
separate discussion for it
Tommy Pauly:
Nonces:You're not using redemption contexts but each token has a nonce
in it
Scott: yes. We should talk about it in the spec
Tommy: we should adopt it in some extension
Question overall for use of extension here. How applicable are they to
adhoc scenarios like privacy relay. The entire infrastructure knows what
they are doing together
vs
tokens with extensions they don't know about.
Right way to think about applicability
How much does the client needs to understand the semantics of expiration
Scott: draft gets into that. Issue open around challenging a extension
type. Letting clients handle those
Tommy: Client does need to understand it. Applicability on the web
discussion to make sure we don't segment user population on extensions
they support
You want all users to use a set of extensions together
Ben Schwartz: A lot of these extensions are proprietary, seem to be
coupled to your google system here.
Do we consider some other kind of registration policy other than
Specification Required?
Scott: You can't block on a particular extension ID. Standardisation
takes time and we shouldnt block on a number
Nick Doty: How does the client choose what expiration it needs/ gets
It seems that the privacy properties will depend dramatically on the non
standardised piece.
Scott:
In the case of non proprietary component: When agreed on params, there
could be an alignment value negotated e.g. round this to a day
Need to make sure it works for both proprietary and public ones
We should find a way to make this work.
Steven: You're only going to use these tokens in this usecase. Choosing
some but not having overlap is not very manageable like in TLS
previously.
Privacy pass used a single bit about user
inescapable trafeoff:
too many: privacy impact
Too few: origins dont get what they need
Incescable tension between putting in everything vs minimum
A solution
anonymous credential
It can decide what fields to reveal depending on origin needs
User agents can enforce privacy and issuer attributes
Challenge:
One token
Rate limtiing
Origins need to advertise what they want
Alternatives:
Schemes, you can't use SD JWT, cant just throw in a blind signature.
Hash is linkable
Questions for WG
Is this a problem, should we solve it?
Martin:
If youre not able to hide that first bit, that you have a token or
something inside.
Youve hidden other stuff, thats great. Like the BBS stuff but there's a
narrow gap between contexts that cant tolerate the one bit, or context
where the other bits dont present a significant challenge
I think im fine with other stuff just being in there
Not sure about the privacy story there
Tommy:
I am not a cryptographer. It seems to be cool and have nice properties,
but adding it to the zoo of things and how to use it is nice.
Saying that we have a better more efficient way to achieve the same
thing. I think you should pursue it and work on the document.
Discussion about when you should use what types should be separate
Nick Doty:
Still trying to understand the proposal and implication. This would give
the property of unlinkability.
Watson: What we're trying to achieve is selective disclosure. Include
exactly what needs to be issued.
Nick: Selective disclosures out there with unlinkability are out there.
We should fit the privacy pass one
Watson: We should think about doing this for privacy pass like spice.
Ben: wide range of ideas here. Group charter has language about tokens
and metadata. We might have to recharter if it doesn't match that
description.
Scott:
Not a BBS expert but could fit well with the extension negotiation
problem we talked about before.
Selected disclosure might be a way of solving the thing discussed
before.
This could be combined
Joseph:
There is some potetial interest in this
2-3 usecases of privacy pass APIs
Private access tokens
issuer tester model
Private state tokens
not quite privacypass, doesnt do auth
uses the batch spec in a way it isnt defined might be resolved
eventually
Chrome IP Protection
Blind RSA tokens with metadata
Attester/Issuer Ecosystem
Single/Fixed attesters
Fixed meanings and attesters can be trusted
Arbitrary attesters
lots of attesters
can't rely on small well known ecosystem
Fuzzier meanings of tokens add complexity on what the privacy is
Challenges:
Limit redepmptions across multiple issuers
Don't want to be stuck with chosen attesters
Binding redepmtion in a context
when youre redeeming you can timing attacks. Small issuers with few
visitors can have time attacks
Token questions, we made some decisions and some we can solve more
broadly
If you have multiple privacy pass layers, potential privacy issues
Meaning of tokens changing over time, adds entropy to the token. Bunch
of keys on one day, different on another. Sort of mentioned in drafts
but needs more work
My interest is in privacy pass in browsers, example Apples acces tokens
and google's state tokens
Not cloudflare extension
2 auth modes here in privacy pass:
loose coupling in the thing youre authorising and token.
Uses of privacy pass rely on activation energy. You dont want to be
asking permissions to put tokens in browsers, adding friction
Low stakes authorisation
Crypto doesnt eliminate limit in trust but reduces it
Privacy is good, we need to ask difficult questions
Designs need to account for information leak. Timing carries information
Transport metadata (IP) does too
Loose bindings:
privacy pass
Don't necessarily get to narrow things down, binding to origin or time
or proxy.
Trust we make on how much privacy we want to provide
Tommy: At least for how we define origin skipping, origin can choose to
go to you. From the perspective
Martin
Bind to specific origin, prevents expansion of anonymity set.
Tommy
Either case, give me one token that I can't correlate to anyone else.
Martin
Set of people that present origin bound ones are in the anonymity
Who trusts whom, decision in deployment
Trust in one direction but not the other and we need to think about that
From client perspective: meaning of that bit: additional metadata in BBS
is good, meaning of the bit is unknowable
Meanings that are not okay
Information CAN get passed to issuers
Could mean anything, trust assumptions get you the meaning. No guarantee
bit means anything in particular, no guarantee about the size of
anonymity set
Trust in etntities that are operating
We dont have trust on the web
Options here like google attestation or registration
We might trust cloudflare but they cant be the only provider. But how do
we trust others?
Apple's solution, only one attestor and small issuers. They are
genuinely trustworthy
on the other end. Private state tokens on any website. If trust is
everything, they can pass around 6 bits of info they can pass around so
don't know if its good enough
Sovereign identity providers: being discussed. Most of us have an ID fro
the government. Existence of those could be used. Signal is, you have a
government issued doc
Not privacy pass at that point, but could be used for anti fraud
Steven Valdez:
Apple registration: for issuers. Bad issuers add problems, they cant
choose reasons
Tommy: yes currently the default beahvior is the default attestor. If
you want a large anonymity set, we're relying on the fact that the
issuer is used by many clients.
Apple's solution: guarantee the size of the anonymity set.
The trust relationship is that only the origin trusting the issuer. If
the issuer wants to downgrade its value, origins should choose not to
work with that issuer, and it shouldnt downgrade its value even if it
goes trhough the same attestor
How do we get firefox on linux having attestor that is reasonable
Scott:
Suggest what tommy has included. Key consistency part of this problem.
Metadata defines clients anonymity set and we need a way to measure the
actual anonymity set
Push towards something thats an evolution of key consistency, we could
solve a lot of these problems
Knowing exactly what the client wants us to do.
We need to define what are the bounds of the anonymity set
Ben Schwartz: 2 ideas
one is when we're gonna be concerned about privacy, we will have some
sort of proxy
consider that we already have an entity in the system that is trusted in
this way and leverage that
other thing, instead of assuming every issuer leaks info about the user,
have origins attempt to redeem tokens from different issuers and fail
until they succeed and no longer be able to make further request. Walk
the list until the positive answer, but cant combinatorially check which
subset of users were issued by whom
Watson: responses here are missing something. Its not that we dont have
large anon set, more like we dont know the meaning of the bit. Real
challenge especially with metadata
Steven: We're trying to enable more generic cases that are privacy
preserving. Using privacy pass but using more governance. Not just
arbitrary decisions by parties
Presence or asking token can leak info
Nick Sullivan:
Context: oauth based capture. Didn't work out due to privacy reason but
might work now. There were issues back then, the governance question is
hence an important question
Thibault:
what do the issuer provide, could be useful info to verify issuers
Nick Doty:
When these issues occur, granularity, freedom, rigidity are considered.
A single bit doesnt tell what a bit is, and a large number is more
exploitable than the single one
Rigidity, we need to make it work even if user doesnt have token.
Talking about preventing large scale attacks without discriminating
users
Mark Nottingham:
Skeptical of coming up with a governance structure that works.
Consolidation and centralisation were mentioned.
We usually try to leverage existing centralisation. Here we're deciding
what that bit means and should focus on that
Tommy:
Comment on Watson's comment. Anonymity problem can be related to the
meaning of the bit
If I the client, know the attestor is used by many clients. Bit becomes
common denominator between me and that attestor my clients are going
through.