Mimi 2023 Sept Interim

• Note well the note well
• Topic is user discovery

Chair Slides

Requirements

• Last interim
• Map service independent to service specific identifiers
• Phone and emails, but emails not at messaging providers
• Open problems
  • Who is trusted to provide it?
  • Scale of service providers
  • Privacy risks and mitigiations
  • How many results returned? Do we query all service providers or
    put to users?

Solutions

Hogben & Olumofin

Giles Hogben presenting

• Additional requirements

  • No single entity responsible for resolving all discovery
  • Costs proportional to userbase
  • Query every contact once every 24 hours

• Tim: QPS 24 hours per user function of new conversation frequency?

• Giles: also keying material frequency
• Client fan out leaks too much
• Central hub is too expensive for one person, politically complicated

• Prefered option: federated resolver service

  • PIR to map SII to provider
  • Client goes to provider

• Jonathan Rosenberg: assuming each provider directly participates in
  resolution, no discovery provider

• Jonathan Rosenberg: client phone, or different messaging service?
• Giles: client is the phone
• Konrad: SSI only, or key distribution?
• Giles: SII is a blob, could be whatever
• Each provider publishes all mappings they know to each other, client
  PIR queries them
• Jonathan Roesenberg: What are these entities? What relationships?
• Giles: some of these might be combined. If Platform 1 is small,
  Platform 2 whatsapp don't want to do PIR on all of WhatsApp
• Jonathan: not intrinsically hostile to discovery provider different
  from service provider
• Alissa: first two arrows optional for platform that wants to cache,
  given platform might take it for some, not others.
• Giles: caching mutually agreeed
• Alissa: after discovery, right to bottom half
• EKR: what role is PIR playing here? The two halfs are owned by the
  same person big leakage
• Giles: key request tunneled via platform 1
• EKR: maybe confused about what we're trying to do. Is it conceal
  platform 1 that talking to specific person on platform 2?
• EKR: restatement of design: pair of platforms using the conversation
  know whose talking others don't.
• Olumfin: multiple numbers, multiple services. Really don't want
  single nameserver to learn social graph completely. Could make sense
  to use PIR for that stage.
• Giles: applies to cache
• Watson: where does keytrans fit in?
• Giles: After key distribution
• Tim: Does platform 1 frontend get to choose what SII to return?
• Giles: Next slide
• Tim: how does client express preferences about whats prefered
• Giles: next slide
• Blob includes signature by user of what is prefered
• Konrad: isn't this key provider specific? What about changes?
• Giles: can get all keys, then verify which one is prefered
• Giles: how often refreshed determines how responsive to changes
• EKR: is issue client wants A, but B asserts they really want B.
• Giles: and worse, meatbag A SII 1 with service A, meatbag B SII 1
  with service B, asserts prefered
• EKR: inherently speaking phone numbers are SII
• Giles: also strings without identity
• EKR: even phone numbers services can assert membership. Need to punt
  to CA
• EKR: do think we need correctness mechanism about services they want
  to receive in are correct. Acquiring new ones shouldn't force
  changes on back.
• Jonathan: two new entities! What are the people who run them,
  cardinalities?
• Giles: service UI means platform 2 nameserver, place of
  registration, resolver is platform 1 frontend or nameserver
• Jonathan: cardinality issue: consumer can have multiple ones,
  multiple phone numbers. Registering preference, where do I register
  it
• Jonathan: can't assume people will clean up
• Many slides on PIR
• Jonathan: heard data ahead of the query? Main foundational
  complication is who they are and trust and cardinalities
• Giles: think we need to flesh this out in the document
• EKR: excited about PIR need to figure out threat model and where
  endpoints are, and if we can convince ourselves user trust provider
  much easier
• Alyssa: think we might need CFRG, but we're still early in
  development here

Rosenberg

• Separation between discovery and application provider because of
  trust
• Lots of applications, incl. self-hosted, hundreads
• How many discovery providers? More than one, less than 10
• Geopolitical boundaries
• High trust, exist only because of provider
• EKR: geopolitical nonstarter
• Jonathan: discovery providers > 1. If one requires uploading PII to
  everything. Hearding cats to get one. Esp. with GPDR.
• EKR: what's the security around this data? Is it inherently public?
• Jonathan: email and phone are GPDR personal info, connected to
  provider
• EKR: need to decide if we're going to prevent scraping it all. Don't
  think we can and impact limited. Start with what we're trying to
  accomplish. Access control? Then who gets access.
• Jonathan: assuming not acceptable for signular place, limits on
  where it can be stored, e.g. not all on Cloudflare
• Jonathan: sensitive in aggregate, e.g. messaging customer base size.
  Some access necessary but limit to query response
• EKR: scraping is hard. Any moderate size provider will query
  basically the whole thing. 10 million users, each 100 adjacency, 1
  billion queries
• Jonathan: whatsapp has 1 billion records. Small provider badguy.com
  has 10 users. Agree can't stop Apple from getting list of all Google
  users. Think 3 of them.
• Alissa: helpful to distinguish between databases because access to
  it. Sideshow because distributed, each operator managing compliance
  isn't an issue. Who gets to know what about access is something we
  need to get agreement on. Alice talks to Bob, Alice on A, Bob on B,
  A knows Alice talks to someone on B, B learns Alice wants to talk to
  Bob, no one else learns
• Jonathan: don't think one provider having all the data is the
  solution.
• Alissa: strong assumption application providers also discovery,
  don't need to have this conversation
• Do we have independent and application providers? yes
• Jonathan: smaller messaging providers that can be enterprises. Some
  malicious how to get trustable mappings. One way is separate
• Watson: feels like a solution statement: Alissa has the problem
  statement
• Jonathan: Issue is that user is customer of provider B. Malicious
  provider when user not user of a services. Would therefore be able
  to see a query each time refresh happens. Many protocol designs get
  queries to discover the phone number
• Giles: don't see how you solve without allowlist for participating
  in the discovery system
• Jonathan: the slides comming explain the solution
• Giles: Agree we need multiple mapping, not GPDR, data is "there is
  an account with X" is already public. Need possibility of discovery
  not service provider. Naive to think only large players who can run
  a discovery service
• Tim: I think we agree on cardinality, shape of trust problem,
  bazillions and some shady so other trust anchor. Depart in system
  for distributing the information. But distribution and trust
  different: look at web where DNS shady, CA not. Overall idea of
  vetting the mapping is not distribution problem
• Jonathan: then a scale problem. if dozens hardcode, if have to know
  about every one and query and validate on return seems harder. Since
  you already have central why not distribute
• Jonathan: app provider internalizes, if not a user queries up in
  GLADOS provider
• EKR: why reify the choices on the wire?
• EKR: strawman of PIR query everyone, client gets result. Why not
  client policy
• Jonathan: iMessage willing to query user not authed?
• Jonathan: the people don't want it, because of the EU they are doing
  it. Ask only flow for people on the outside. Minimize arch
  disruption.
• Jonathan: Glados validates mappings through user interaction. No
  change to flow for phone validation
• Watson: why not a public key?
• Jonathan: sure
• EKR: Not sure why validating the given entity has right identifier
  and distributing that information. Really validate identifier maps
  to person not provider
• Giles: validation proves I know the phone number, not account with
  AP X
• Jonathan: because you entired it into your application

• EKR: Some providers will directly assert. Others not accept. But
  from that premise much more natural to have GP accept assertion from
  certificate, GP trusts CAs including WhatsApp. Mechanics of running
  CA very different from distribution.
  # Remarks from chair {#remarks-from-chair}

• Progress on cardinality and social graph privacy goals. Draft
  deadline two weeks from now, great to get updates reflecting
  discussion and clarifications and starting to think if we might be
  talking about same solution or something a little different