Detecting the Presence of a Malicious Hub in MIMI Protocol

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 8 January 2026.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The MIMI architecture [I-D-mimi-arch] [I-D-mimi-proto] uses a hub as the center of each room, which is also responsible for routing and timestamping all messages. It employs MLS [RFC9420] for end-to-end encryption (E2EE) and security. If a hub is compromised, it can take advantage of the trust vested in it by the MIMI protocol. This can affect the integrity of the messages being routed through the hub, including, but not limited to message dropping, message reordering, targeted censorship attacks, etc [I-D-mimi-content] [E2EE-Attacks]. With this detailed example below, we will demonstrate few of the possible attacks that a compromised hub can execute. We are considering a group chat between Alice, Bob and Charlie.¶

Message reordering attack:¶

• Seen by Alice:¶
• 08:00 Alice: How to fix the system?¶
• 08:02 Bob: Press X, it should work!¶
• 08:03 Alice: I pressed X, the system crashed! ¶
• 08:04 Charlie: Do not Press X, the system will crash!¶
• 08:08 Charlie: I told you not to press X, but you went with Bob's suggestion.¶

• Seen by Charlie:¶
• 08:00 Alice: How to fix the system?¶
• 08:04 Charlie: Do not Press X, the system will crash!¶
• 08:06 Bob: Press X, it should work!¶
• 08:07 Alice: I pressed X, the system crashed! ¶
• 08:08 Charlie: I told you not to press X, but you went with Bob's suggestion.¶

Now, in the scenario presented above, Charlie sees a different version of the chat than Alice, which creates a misunderstanding between Alice and Charlie. Charlie thinks that Alice decided to go ahead with Bob's suggestion and ignored his suggestion even though it was sent first, whereas Charlie's message arrived after Alice had already acted upon Bob's suggestion. Here, the hub reordered message timestamps for Charlie, undermining the integrity of the group chat.¶

Shown below is another example, where the hub specifically dropped or censored messages from Charlie, such that Alice never sees any messages from Charlie. This is a targeted censorship attack from the hub. Also, from the context of the messages, Charlie assumes that Alice provided an update in response to his message, whereas Alice never saw Charlie's message and was updating Bob, due to which the malicious hub also avoided being detected.¶

• Seen by Alice:¶
• 08:00 Alice: How to fix the system?¶
• 08:02 Bob: Press X, it should work!¶
• 08:07 Alice: I pressed X, the system crashed! ¶

• Seen by Charlie:¶
• 08:00 Alice: How to fix the system?¶
• 08:02 Bob: Press X, it should work!¶
• 08:04 Charlie: Do not Press X, the system will crash!¶
• 08:05 Charlie: Any update Alice?¶
• 08:07 Alice: I pressed X, the system crashed! ¶

As per [I-D-mimi-content] [E2EE-Attacks], message reordering, and traffic analysis attacks are practically possible, even with E2EE being in place. The draft MIMI specification does not offer any solution for detecting or countering a malicious hub. The protocol described in this document introduces a client-driven audit layer to detect malicious hub behavior without the need to modify the hub, and the need to add new trusted servers, with practically minimal resource overhead. Following the proposed protocol, each client maintains a timestamp-ordered list of messages from the client perspective, while continuously maintaining a Merkle root for the list. With a random probability 'alpha' the client broadcasts the Merkle root to the group with a regular encrypted group message. On receipt of this message, each client individually verifies the Merkle root against their local list of ordered messages. If the Merkle root does not match with even one of the clients, the client raises an alarm, indicating a malicious hub.¶

2. Threat Model

Based on the examples and discussion in the previous section, we propose a formal threat model for a MIMI hub, as a critical point of security failure in the MIMI protocol. The threat model will be defined by the following three components:¶

1. Timestamp Authority of the hub enables it to back-date or falsify timestamps, leading to a timeline of messages that can be misleading.¶
2. Re-ordering via delay is another property of a malicious hub that causes downstream clients to see an arbitrary permutation of actual messages, due to the hub selectively delaying certain messages.¶
3. Isolated views indicate that clients are only dependent on the hub for receiving and sending messages, and have no other way of cross-checking the order of the messages received.¶

The Theat Model represented in Figure 1, represents a message reordering attack where, the messages sent by Client B and Client C get reordered by the malicious hub Server A, such that Client B sees a different order of messages than Client C and Client A.¶

ClientB   ServerB      ClientC      ServerC       ServerA        ClientA
 |            |            |            |             |              |
 |    M_b     |            |            |             |              |
 |----------->|            |            |             |              |
 |            |              /submit M_b              |              |
 |            |-------------------------------------->|              |
 |            |            |   200 OK   |             |              |
 |            |<--------------------------------------|              |
 |  Accepted  |            |            |             |              |
 |<-----------|            |            |             |              |
 |            |            |    M_c     |             |              |
 |            |            |----------->|             |              |
 |            |            |            | /submit M_c |              |
 |            |            |            |------------>|              |
 |            |            |            |    200 OK   |              |
 |            |            |            |<------------|              |
 |            |            |  Accepted  |             |              |
 |            |            |<-----------|             |              |
 |            |            |            +----------------------------+
 |            |            |            |Malicious reordering: M_c is|
 |            |            |            |delivered first to ClientA  |
 |            |            |            +----------------------------+
 |            |            |            |             |     M_c      |
 |            |            |            |             |------------->|
 |            |            |            |             |     M_b      |
 |            |            |            |             |------------->|
 |            |            |   /notify M_c            |              |
 |            |<--------------------------------------|              |
 |     M_c    |            |            |             |              |
 |<-----------|            |            |             |              |
 |            |            |            | /notify M_b |              |
 |            |            |            |<------------|              |
 |            |            |     M_b    |             |              |
+----------+  |            |<-----------|             |              |
|M_b -> M_c|  |            |            |             |              |
+----------+  |       +----------+      |             |              |
 |            |       |M_c -> M_b|      |             |              |
 |            |       +----------+      |             |     +----------+
 |            |            |            |             |     |M_c -> M_b|
 |            |            |            |             |     +----------+
 |            |            |            |             |              |

3. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

4. Protocol Design

The proposed mechanism is designed based on Merkle proof generation. Merkle proofs are generated using Merkle trees where each leaf is represented as a hash function of a message and its timestamp. The proof is calculated using the leaf nodes and if the message order is tampered with in any way, the proof generated will vary. This will help identify if the hub is malicious as it handles all the message routing and distribution mechanisms. The proposed mechanism is broadly divided into three components, which are described below:¶

Algorithm 1: ComputeAndBroadcastMerkleProof(Lm, s, e)

Require: List of sorted messages Lm = M[1,...,m],
indices 1 <= s <= e <= m
Ensure: Proof tuple (R, t_max, s, e)

procedure ComputeMerkleProof(M, s, e)
    leaves := []
    t_max := 0
    for i := s to e do
        (d_i, t_i) := M[i]
        l_i := H(d_i || t_i)
        leaves.append(l_i)
        t_max := max(t_max, t_i)
    end for
    R := BuildMerkleTreeRoot(leaves)
    return (R, t_max, s, e)
end procedure

procedure BroadcastProof(alpha)
    if Bernoulli(alpha) then
        Broadcast(R, t_max, s, e)
    end if
end procedure

Algorithm 2: ProofVerificationAndBroadcast

procedure OnProof(R, t_max, s, e)
    compute leaves l_i = H(d_i || t_i) for i in [s, e]
    R_hat := ComputeRootFromLocalMessages(s, e)
    if R_hat != R or t_max != max_{i in [s,e]} t_i then
        RaiseAlert(ProofMismatch)
        Broadcast(ProofMismatch)
    end if
end procedure

5. Security Considerations

A compromised client is one of our primary security considerations that could undermine the efficacy of the proposed detection mechanism. Since a client is independent or autonomous in terms of Merkle proof generation, if compromised, it has the ability to generate fake proofs, which can lead to false alarms by other clients. Another possibility is that the compromised client generates a false alarm. Even if the received Merkle proof matches the locally generated proof, the client might raise a false alarm, disrupting communication or causing overheads to re-establish secure communication. To potentially mitigate the generation of fake proofs, cryptographically signed Merkle proofs could be used to verify the origin of the proof, potentially preventing proof spoofing.¶

A compromised client can also pull off a Denial of Service (DoS) attack by flooding the group with proofs or mismatched alerts. This may lead to higher communication overheads for continuous Merkle proof computations and verification against multiple proofs available on the group. This may also cause alert fatigue and confusion, generating irrelevant alerts due to a compromised client rather than a compromised hub. Dealing with this issue requires setting policies for handling alerts, including but not limited to limiting the rate of proof generation and broadcast, aggregation of alerts, and explicit alert handling to detect the presence of a malicious client.¶

Similar to post quantum decryption consideration for MLS, Merkle proof generation by the proposed mechanism can also be affected by the security of the underlying algorithm for proof generation. Another consideration would be the collision resistance property of the algorithm used for proof generation, which can potentially undermine the integrity of the generated proofs. Choosing and optimizing the available hash functions to suit the security and overhead requirements for Merkle proof generation is key in maintaining proof integrity. Algorithmic agility is another key component to rapidly switch between cryptographic algorithms as a response to emerging threats to the integrity of the proofs and the overall communication integrity.¶

Another point of possible intrusion could be the follower servers. A compromised follower server may do internal message reordering or dropping, acting as a malicious hub for its clients. In such a case, the MIMI hub will be the one held responsible, whereas the malicious follower server will bypass detection. To mitigate this situation, it might be a good idea to apply the audit-layer detection on the follower servers internally, while keeping the communication overhead minimal.¶

6. IANA Considerations

This document has no IANA actions.¶

Acknowledgments

We gratefully acknowledge the valuable feedback and constructive discussions received within the working group, in individual conversations, and during the MIMI interim meetings.¶

Authors' Addresses