Re: [Mimi] Some thoughts on introduction and discovery

[Antoine FRESSANCOURT <[e-mail]>]

Hello,

Thanks for raising those points. I will not address the security aspects of things, but on the architectural aspects of your message, I would like to make a trip in the past and give some hints about how a similar problem has been addressed in systems using the SIP/SIMPLE protocol.

The IMS architecture has been designed in the mid 2000’s to address some issues related to the deployment of VoIP / next generation networks for telcos and ISPs. This architecture is using the SIP protocol for signaling, and in the wave of the design of this architecture, several so called “basic services” have been defined. On of those services is the Presence service. This service involved a sequence of SIP signaling messages.

In IMS, the server responsible for a subscriber’s presence can be accessed from external domains. The discovery mechanism involves DNS entries (NAPTR records, to be precise).

In SIP / SIMPLE, one can subscribe to events, and to events interest. So, for instance, Alice’s presence event is mirrored by Alice’s presence interest event. Whenever someone tries to subscribe to an event, a notification is sent to the observers of the presence interest. When an external observer is interested in Alice’s presence, this observer sends a SIP SUBSCRIBE message to the presence server. Then, the presence server can send a SIP NOTIFY message to Alice as Alice is supposed to be a subscriber to her own presence interest event. On reception of this notification, Alice can accept or deny the subscription, either using a SIP response (403, or other) or by sending a 200 OK after reaching to the presence server through a Web API. In this response, the filtering preferences of Alice with regards to the observation made about her presence can be stated in the form of a XML preference document. If Alice accepts the request, the presence server sends a 200 OK response to the observer, followed by a notification message stating the initial presence state. Whenever there is a change on Alice’s presence, Alice publishes this change to the server, and the server applies the filter given by Alice before cascading this presence change to the observers.

I think the message exchange that is used to make sure that Alice consents to the subscription before the observer can actually see Alice’s presence can be replicated in the invitation sequence that you mention. I guess publication / subscription signaling may not be using SIP per se, though.

Best regards,

Antoine Fressancourt

From: Mimi <[e-mail]> On Behalf Of Eric Rescorla
Sent: mardi 21 mars 2023 14:50
To: [e-mail]
Subject: [Mimi] Some thoughts on introduction and discovery

I've been doing some thinking about the overall MIMI architectural
questions and wanted to try to focus on one in particular, namely
around setting up communication.  At a high level, we have the
following three main scenarios, in descending order of Alice's
knowledge:

1. Alice knows Bob's provider and an identifier within that provider
   scope (e.g., a phone number and that he uses WhatsApp) (an SSI).

2. Alice knows some sort of unique identifier for Bob (e.g., an E.164
   number or an e-mail address) but not what provider he is using
   (an SII).

3. Alice knows some out-of-band identifier for Bob but not any instant
   messaging address (this is what draft-rosenberg-mimi-transport
   assumes).

In all of these cases, we want to go from that identifier to a
situation where Bob has consented to communicate with Alice or what
many systems would call being a "contact". Once that relationship
is established, Alice can message Bob or try to add him to groups.


# Security Requirements
Many of the security requirements are covered by MLS, but not all.

Spam
: In discussions so far, we've assumed that one of the primary
requirements is that Alice not be able to spam Bob. Specifically, that
she should not be able to send messages to Bob or add him to groups
without first getting his consent. She should also not be able to use
invitations as a form of spam.

Consent to join groups
: JDR's draft seems to assume that Alice shouldn't be able to add
Bob to groups without his consent. I think we should discuss this,
as most systems I am familiar with do not have this property,
especially for 1:1 messages. Even for larger groups, may systems
allow people to be added but they can remove themselves.
It's important to distinguish two cases here:

(1) Someone is added to a group but doesn't have to see the messages.
(2) Someone is added to the group and also gets all the messages.

One can imagine a design where you are always added to groups
at the MLS layer, but the messages are quarantined until you
join.

Key Exhaustion
: It should not be possible to Alice to exhaust all of Bob's KeyPackages.

Privacy for service discovery
: In the case where Alice doesn't know Bob's service, we need to decide
whether she needs to consent before he can discover it. I think there
is an obvious privacy argument here, but it's generally possible to
test whether Bob is on a *specific* service, and there may be a tension
with privacy for contact discovery.


Privacy for contacts
: Ideally it would not be possible for arbitrary people to determine
who Alice's contacts are. When Alice messages Bob, it's probably hard
(though not impossible) to conceal this from their respective
providers, but ideally (1) no third party should know and (2) the
providers shouldn't know if Alice just has Bob in their contact list
(e.g., in your OS phonebook) but hasn't actually asked to connect.


# Thoughts On Architecture

I think we should start by trying to solve scenario 1, in which Alice
has an SSI for Bob. This is clearly easier than solving (2) and I
don't think (3) is an acceptable user experience.  This also lets us
build a staged solution where we have a separate system that goes from
an SII (1) to a SSI.


## Establishing Consent

In the existing closed systems, the basic consent idiom is that Alice
is allowed to send Bob an invitation to connect, typically with no
message (e.g., "Alice would like to connect") or maybe some kind of
very restricted message (e.g., only a few characters). Given that
Alice already has Bob's identifier (by assumption), this is
straightforward technically. These restrictions don't make spam
impossible of course. For instance, you can change your Display Name
to be a spam message. We don't have too much information about how
these platforms control spam, but presumably they do some kind of
monitoring of the number of messages people send, acceptance rate,
etc.

Obviously this is harder where we don't have a single system, so we
need to figure out how to address that. There's some obvious tension
here because a lot of the obvious designs involve being able to see
the connection graph of the inviter (and potentially the invitee),
which has privacy issues. It seems to me like there there are several
main approaches here, which we can sort of mix-and-match:

- Trust the inviter's side to do all spam prevention, but with
  the peer having the option to defederate if the overall
  stats look bad.

- Trust the inviter's side to provide overall reputation data
  for the inviter (e.g., number of connections, number of
  outstanding unaccepted connections, etc.) so that the peer
  can do spam suppression.

- Have some level of public and verifiable information about
  the inviter's connection status (insert crypto handwaving
  here if we also want privacy) that the peer can use.

I think we need to know a lot more about how existing systems
behave before we can design something in detail.


## Consent and Messaging

Once Alice has Bob's consent, then she can send him a message.
However, if we explicitly serialize these then we add a lot of
latency. I.e.,


Alice              DS                  Bob

                                 [Offline]
Connect? ---------->
[Goes offline]
                      ------------------->
                             [Goes online]
                     <----------- Accepted
                       [Goes offline]

[Goes online]
<---------- Accepted
Hello ------------->

                             [Goes online]
                      Hello ------------->

A better user experience is if Alice can send a message in parallel
with her connection request but that Bob only sees it if he accepts
the connection. I.e.,

Alice              DS                  Bob

                                 [Offline]
Connect? ---------->
Hello ------------->
[Goes offline]
                      ------------------->
                             [Goes online]
                     <----------- Accepted
                      Hello ------------->


In a non-E2E-encrypted system, this is straightforward, but in
an E2E system we need to worry about KeyPackage exhaustion by
Alice. It seems like there are a number of possible designs that
would work here, including:

- Rate limiting KeyPackages to non-contacts
- Having a special non-contact KeyPackage that didn't necessarily
  offer PFS.
- The same kind of anti-spam systems we discussed above.

In either case, once Alice has connected with Bob, I think we should
probably let her send group invites and messages concurrently.


## Identifier Discovery

If we just had a design that fixed the SSI problem, tahen we would
actually be in not terrible shape. It's annoying to have to pick
people's service from a list, but it's better than nothing.  Moreover,
if we have a solution to the consent problem with SSIs, then we can
try to build a separate lookup mechanism.  for mapping an SII onto an
SSI. At a high-level, there are two clases of solution:

- Contacting the user using the SII (a la SPIN or draft-rosenberg-mimi-transport)
- Directory systems

The main drawbacks of contacting the user directly using the SII is
that it's clunky. In addition, some variants (SPIN), it depends on
non-open properties of the receiver's client device, which isn't
ideal.

The main challenge with directory systems is privacy. As noted above,
there are potential privacy issues. The obvious design is just to
publish a directory mapping any SII to the set of SSIs/services it is
associated with, but this minimally allows the set of federated
services (which in an open system means basically everyone) to learn
the contents of the directory. In addition, the directory service gets
to learn that Bob wants to call Alice, whereas ideally just Alice and
Bob's providers would learn about it.

I've been doing some thinking about crypto-type designs for addressing
these issues
(https://educatedguesswork.org/posts/messaging-discovery/#privacy),
but it's not really perfect, and it's only a partial scraping defense.

-Ekr