PRIVACYPASS at IETF 118

(Notes by Chris P.)

Drafts

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

(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

(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

(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.