Skip to main content

Minutes interim-2023-mimi-10: Tue 14:00
minutes-interim-2023-mimi-10-202310101400-00

Meeting Minutes More Instant Messaging Interoperability (mimi) WG
Date and time 2023-10-10 14:00
Title Minutes interim-2023-mimi-10: Tue 14:00
State Active
Other versions markdown
Last updated 2023-10-24

minutes-interim-2023-mimi-10-202310101400-00

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