The flaws are in fact not being patched appropriately. For instance: the project told the researchers that they were "accepting the risk" that malicious homeservers could spoof group memberships. In Matrix, group membership equates to the ability to decrypt messages; that's an extremely weird "risk" to accept, isn't it?
The risk being accepted is that a homeserver can currently add members to the group with the group being notified of this.
This risk will be removed completely once TOFU and signed control events are implemented, which is planned (and was planned before this research). It's just more work than could fit in the disclosure timeline, especially because it's a large change needing ecosystem coordination.
I don't think "the group being notified" that an unauthorized member can decrypt all their messages is quite the mitigation that Matrix advocates think it is.
This is the fundamental task of any secure group messenger. It has really one job: don't let unauthorized people read messages for the group. Here, Matrix has apparently accepted the risk that their group messenger can't do that job if the server is compromised. If you know where to look and your group is small enough, you can constantly watch to see if your homeserver has decided to stop protecting your group, but either way: your homeserver can spontaneously decide to stop protecting your group. Matrix, you had one job!
At the point where you accept this risk, you might as well just use Slack.
Your suggesting to use Slack, where a similar compromise would reveal your entire account message history.. ? Just enforce proper key verification for now and you're fine..
I genuinely do not understand the impulse people have to rationalize stuff like this. This is a devastating research result. It might be the most damaging paper ever published on a secure messaging system; I'd have to think about that.
For what it's worth, i just did a quick survey of other secure messaging systems to see how they manage group membership. These days Signal uses zkgroups as per https://signal.org/blog/signal-private-group-system; it looks like Wire is somewhere in a transition to MLS for client-managed group membership (although historically membership looks to be entirely controlled by the server). I dread to think what WhatsApp or iMessage do (anyone know if membership is server-controlled or not?)
So yes: we should switch to client-controlled membership management, and we've already started the work to do so. However, the Matrix spec and its implementations has always been transparent that it's up to the user to verify the membership of the room - for after all, if they don't bother verifying users, then all bets will always be off anyway. For instance https://element.io/blog/e2e-encryption-by-default-cross-sign... explicitly says: "You’ve verified this user, but they have risky unverified sessions logged in! A room containing any red users is shown as red." I'm not sure this exactly counts as a research result, let alone a devastating one.
However, totally agreed that we can improve on this, and we're on the case.
No, of course not: it's part of the premise of a secure group messenger that the server can't control the groups. Which is what makes it so incredible that Matrix screwed this up so completely.
