Re: [Mimi] Messaging Transport for mimi

[Konrad Kohbrok <[e-mail]>]

Hi Suhas,

Thanks for the proposal for a MIMI transport architecture. A few 
comments and questions.

Relying on previously arranged business relationships essentially 
restricts the architecture to a bilateral model (as per Jonathan’s 
taxonomy document) and in particular does not allow for an open model. 
It also precludes the participation of individuals or other entities 
that cannot (or will not) enter such a business arrangement. Such a 
closed approach is also at odds with the DMA, as it reinforces current 
monopolies and cements the requirement for a business relationship 
between providers.

Regarding the assumption of E2EE: Do you assume E2EE only for 
application messages, or also for handshake messages? Encryption of 
handshake messages has a number of trade-offs: On the one hand, it’s a 
very effective way of protecting message metadata. On the other hand, 
some information has to be exposed to the server anyway so that it knows 
whom to send the message to. Also, plaintext messages allow the server 
to perform a number of useful functions:

- keep track of the public tree, as well as GroupInfo (clients only have 
to supply a signature), both can be used to make joining easier. On the 
one hand, it allows an external commit (if that is desired) and on the 
other hand, it allows clients to just download the current tree, whereas 
otherwise, it would have to be included in the Welcome message every 
time a member joins
- check validity of messages (except encrypted information such as 
update path values or encrypted extensions), thus preventing individual 
clients from modifying the group state in ways they are not allowed to. 
Servers could thus also enforce group policy. If the server can’t check 
for validity, individual group members can send invalid messages, 
leading to an increase of the Epoch, s.t. if nothing else, other members 
have to initiate a roll-back.

Note that plaintext messages do not necessarily lead to metadata 
leakage. Cached messages and group states can be encrypted at rest and 
per-group pseudonyms can be used instead of real identities.

The way I understand the subscription patterns mentioned in the draft, 
they seem very broad. To prevent the unnecessary leakage of metadata 
across providers, subscription patterns should be scoped s.t. a server 
can check if another server is eligible to subscribe. For example, a 
server should only be able to subscribe to messages if one of the 
server’s users is in a given group, not generally for all groups on the 
server.

To enable an open federation and properly scoped subscribe patterns, 
there should be a way to push connection request messages or group 
invitations regardless of a previous subscription.

- If desired, servers could still perform access control based on the 
sender’s domain based on an allow list or a block list.
- Servers could then subscribe based on the user’s (or its client’s) 
decision to accept or decline the request.
- If the decision to subscribe depends on client interaction, caching 
time should be more than 24h.

Cheers,

Konrad


Am 25.10.22 um 19:54 schrieb Suhas Nandakumar:
> Hello All
> 
>    We submitted a draft describing transport for mimi, called Cached and 
> Async meSsage Transport (CAST), that is inspired by modern cloud based 
> messaging architectures.
> 
> Please find the same here : 
> https://datatracker.ietf.org/doc/draft-nandakumar-mimi-transport/00/ 
> <https://datatracker.ietf.org/doc/draft-nandakumar-mimi-transport/00/>
> 
> We look forward for feedback
> 
> Cheers
> Suhas/Cullen
>