# PRIVACYPASS at IETF 118 {#privacypass-at-ietf-118} (Notes by Chris P.) # Drafts {#drafts} ## Core Draft Status {#core-draft-status} (Ben Schwartz) draft-ietf-privacypass-architecture: IESG approved draft-ietf-privacypass-auth-scheme: WGLG completed draft-ietf-privacypass-protocol: RFC editor -> MISSREF (depencdency on previous drafts) Discussion: * Tommy P.: Do we need to ask AD to resubmit auth scheme? * Ben: Asks chairs to confirm that there are no more blockers * Chair (Joe): WGLC for batched token draft ## Rate-Limited Token Issuance {#rate-limited-token-issuance} (Tommy P.) * Based on the publicly verifiable RSA-blind signature scheme, but allows per-Origin rate limiting * Changes in -03: * Align with work on consistency (draft-group-privacypass-consistency-mirror) * Rate limiting invovles two keys: * encrypting the Origin info (issuer-wide, visible to Attester) * no metadata => per-Origin token keys * => New per-Origin key consistency scheme. QUESTION: Either: * Add per-Origin token keys to the defined config **or** * Allternative: have the mirror "check something" against the Origin * Open issue (#18): More flexible rate-limting contexts Discussion: * Steven Valdez: Multiple origin in the same context? * Tommmy: The thing you're rate limiting is communicated all the way to Issuer => Client is in control of what it reveals => Lots of flexibility, but Clients need to be careful. * Chris W.: Maybe the origin info is not just origins, but could be URLs or whatever else makes sense for the application. * Tommy: Validates our decision in the auth scheme to call it "origin info" * Jonathan: re: Steven: would a reasonable set of origins to rate limit be all domains on Cloudflare? * Tommy: Technically no reason that the origin info must be the same as serving. Origin Info must match the key. How does the client know this is the origin. * Jonathan: What would you do with mutliple CDNs? In different rate limitng domains. * Tommy: Don't rely on DNS. Perhaps a field in the certificate. THe client needs to know in some way. * Chris W.: Auth scheme is rather opinionated about what the names in the origin names should be. If wanted to support this, we might need to rework that text. * Tommy: Rate limit says the Client needs to choose "among the origin infos" the "currently challenging origin" * Jonathan: Every Cloudflare has the same CN \* Nick Sullivan: Not necessarily, but could be a SAN with a special flag * Steven: Multiple overlapping contexts? * Tommy: Let's solve this in this document. Could reject the ones we don't expect to be used. * Chris W.: Don't configure contexts so that there are conflicts? What is the problem: * Tommy: If the list includes example.com and cloudflare CDN and the Issuer accepts both as valid for a rate-limiting context, then the Client is free to choose which it uses. * \[Chris W. <-> Tommy\] Agree the problem is solvable. * \[Nick S. requests clarification of the problem\] * Tommy: CHris W. Offered to propose text to clarify * Chris W.: re per-Origin key consistency: Don't like the solution or alternative, would like to see \[new crypto - partially blind\] could help. (There are implementations, but no CFRG draft yet.) * Tommy: I'n fine with that direction, but it is a working group decision * Jonathan: re alternative: * Tommy: example.com uses AwesomeCaptcha as rate-limited issuer, which has one key for origin name encryption and another that is dedicated to example.com. Need to define some way for the mirror to ask example.com what key it's challenging people with? * Jonathan: Does the .well-known endpoint for the key need to be rate-limited? * Tommy: That endpoint is easy to implement cheaply; you can't do anything to rate limit it. * Ben: We can't rate-limit rejection and serving the keys is less expensive than checking if a token is invalid (and should be rejected) ## Checking Resource Consistency with Mirrors {#checking-resource-consistency-with-mirrors} (Steven V.) Reporting on work from design team for key consistency. Updates since IETF 117: * Simplified consistency checking algorithm * Clarified client behavior when an inconsistency with mirror is discovered * Describe validity period of a successful check Work items * Batch consistency check * Address timing attacks * Application policy and behavior recommendations * Multiple mirrors Next steps: * Call for adoptions * Fix remaining issues * No interim needed Discussion: * Chairs: How many people have read the doc? A few people have (about 7). More feedback would be helpful, but no neeed to block adoption call * Tommy: What do we expect the output of the WG to be around consistency? * Chair (Joe): Not necessarily a problem to publish two documents, but could also merge them into one document. No preference. * Ben: Both drafts are valuable. They implement different patterns that are better for different applications. One standards track and one informational draft is just right. Needs review from HTTPbis * IDEA: The mirror protocol could be cast as a general-purpose tool; let's get feedback from outside of PRIVACYPASS. * Doesn't substantially solve the "thundering herd" problem * Chair: We can ask for review from other groups and still adopt it here. * Eric O.: Thunding herd problem doesn't need to be solved to adopt * Steven: Agree, we don't need to block adoption. There is still a bit of design work to do. * Chris W.: Where would we submit? * Chair: Other group that identified this problem was OHAI. * Chris W.: This is the right group since it's in our charter. * Tommy (HTTP-bis chair hat): Notion that this is the future of reverse proxies is maybe overblown. We should get feedback from HTTP-bis, but making it their goal would hinder the work. * Ori S.: Is this problem about the server serving different keys to different clients? This problem is realted to KEYTRANS. * Chris W.: Our draft is "poor man's" KEYTRANS, so KEYTRANS could be a good fit. # Metadata {#metadata} (Chairs) Unfinished topics: What types of metadata are acceptable? Lots of interest on this topic at IETF 117, and a few drafts. But also lots of concrens. Chairs want to know if there have been additional offline discussions and if we've made any progress. Discussion: * Chris W.: There are operational reasons to include metadata and we believe we can handle privacy concerns on the deployment side. If the group is not interested in metadata then let's remove the registry for it, then the chairs should just make a call. * Nick D.: Expressed concerns at 117 and spent some time reviewing the drafts. There are some mitigations we could standardize that would help. * Tommy: Metadata worries me, but we do need them. Perhaps we can scope metadata to cases we know our safe? E.g.:, metadata is already coming from the challenge from the Origin; there is some information that the Client is already sending to the Origin * Nick D.: Sounds like a promising direction (metadata already known to issuer). Are we going to standardize something like this, or just state the requirement in the draft? * Chris W.: Standardize by only implementing extensions that have that particular property * Ben: Is it posible in some instances to enumerate the possible metadata values? Let's you calcaulate privacy loss. * Nick S.: Could the decision making procdess for which these extensions get included be covered by the charter? * Chair(Joe), Chris W.: Good idea * Chris W.: Requirement: There is a way for Clients to reason about the privacy posture * Benjamin B.: Should there be a document with guidelines? * Chairs: We want to document in some way, document or charter * Ben: charter already include metdata * Tommy: Don't necessarily need a charter change to make progress. The Charter says we can work on metadata already as long as we consider privacy. Not being more specific is helpful. And a cereful consensus call. * Chris W. agrees. * Jonathan snarks. * Chair: * Only include metadata that is already visible? * Only include metadata that is enumerated? * Chair: SHOW OF HANDS: Should we run an adoption call for the first two documents as our basis for tackling metadata? * CONSENSUS is "yes". (19 for, 2 against) * Nick D., Chris W.: Let's discuss if the the expiration extension meets our "requirements" defined in the base metadata drafts.