Matrix: a new specification for federated realtime chat [LWN.net]

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 13:43 UTC (Thu) by Arathorn (guest, #101018)
Parent article: Matrix: a new specification for federated realtime chat

Wow, thanks for writing all this! We (the Matrix team) are rather flattered/scared that LWN thinks it's worth writing about :)

Just to answer a few of the implicit questions in the article and clear up some of the places where the matrix.org spec and website is a bit stale or misleading:

The synapse repository also includes two demo clients: one that runs as a web application, and one command-line client written in Python. The most recent release is version 0.6.1f, from February 10.

The website is stale on this (sorry). We actually have 3 main reference clients - AngularJS (http://matrix.org/beta and http://github.com/matrix-org/matrix-angular-sdk), Android (http://github.com/matrix-org/matrix-android-sdk) and iOS (https://github.com/matrix-org/matrix-ios-sdk). The python commandline one in the synapse project just an HTTP/JSON console for debugging. (There are also other Perl and Python alpha commandline clients - come talk on #matrix:matrix.org if you want to experiment with them).

Also, we just released 0.7.0 a few hours ago, which has *huge* federation performance improvements over 0.6.x.

Second, users that want to connect to a persistent room need only remember the alias to join—if the original server is restarted, the room identifier might change, but the alias can remain the same.

Actually, the underlying opaque room ID can never change; it is shared across all the participating servers. For instance, #matrix:matrix.org is an alias to !cURbafjkfsMDVwdRDQ:matrix.org room ID (affectionately called curbaf to its friends ;). Servers can restart, and join and part from the room, but the room ID lives on. The only time a room could ever change is if a server lost all of its state (and its private key) and created a new room, and advertised an alias of it under the same name. If this happens, it doesn't impact the original room - it just means that another server will have to publish an alias to make it easier to find the original room (e.g. create a #matrix:therealmatrix.org which points to !cURbafjkfsMDVwdRDQ:matrix.org in this example).

Interestingly enough, the specification also advertises a way for users to publicly link a Matrix user ID to a "third-party identifier" (3PID), such as an email address or phone number. To do this, the Matrix network would support a global, federated network of identity servers that maintains the links between accounts and 3PIDs. The goal would seem to be making it simpler to invite another user to join a chat. Unfortunately, the relevant section of the Matrix specification is still empty (marked with "This section is a work in progress.").

...

The sydent server referenced is another GitHub repository, albeit one that has not been touched in five months.

The reason this is WIP is that it's in flux currently. We run a cluster of ID servers (using the sydent project in github) pointed to by matrix.org which work fine and are stable (hence lack of activity on the project), but logically they act as a single entity. They track email->matrix ID mappings (if you sign up with an email address). We want to fix this and make it properly federated ID system supporting multiple 3PIDs (MSISDNs, etc), but we're not there yet (and we want to borrow an existing federated ID system if we can, rather than re-inventing the wheel). Obviously we don't want this to be a SPOF - and the 3PID system is a strictly optional extra anyway.

The traffic on the wire is protected by TLS, but that does not prevent unwanted users from joining what is meant to be a private discussion room. Users who wish to restrict access to a room must rely on Matrix's room-management API: room moderators can kick out users or ban them (by user ID), but little else. Furthermore, although TLS encrypts the messages between servers, the servers themselves have access to the message content. Several spots in the specification and on the Matrix site as a whole make reference to optional end-to-end encryption (where only the users could decrypt the contents of messages), but this appears to be another unfinished component at present.

Crypto and ACLs are slightly different problems. Currently the client-server API allows both HTTP and HTTPS traffic (to support constrained devices which can't speak HTTPS, at the expense of any security/privacy whatsoever). The server-server API mandates TLS, and also signs the transactions (to protect against identity spoofing) and the history (git-style, to protect against tampering). However none of the payloads themselves are encrypted (yet) unless you do so at the application layer.

We do have good support for decentralised ACLs however - we absolutely stop unwanted users from joining private discussions, by supporting invite semantics, and decentralised ACLs where users must quote the historical events that prove that they have permission to join a room (or do some privileged action in the room). This is all relatively mature now, but is a very seperate problem from encrypted messaging.

The story on end-to-end encryption is that we've simply not specified it yet - but we'll heavily encourage people to use it once it exists. The intention is to borrow something like Axolotl (modulo its PFS characteristics).

Anyway, thanks again for writing about us. And LWN readers: please try installing a server and federating up, and come hang out in #matrix:matrix.org; tell us what you think and help us make it better!

to post comments

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 15:04 UTC (Thu) by droundy (guest, #4559) [Link] (3 responses)

> We do have good support for decentralised ACLs however - we absolutely stop unwanted users from joining private discussions, by supporting invite semantics, and decentralised ACLs where users must quote the historical events that prove that they have permission to join a room (or do some privileged action in the room). This is all relatively mature now, but is a very seperate problem from encrypted messaging.

How does this work without ecrypted messaging? I.e. how do you prevent a user from running his own federated server that lets him read the messages in private rooms? Or are you only saying that you can prevent unauthorized users from chatting in a private room? That seems much less important to me than unauthorized listening.

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 17:51 UTC (Thu) by Arathorn (guest, #101018) [Link] (2 responses)

Currently messages are stored in plaintext (or plaintext-equivalent) on servers, so yes, it's trivial for a malicious server admin to sniff conversations. Just like IMAP or or NNTP. It's worth noting that the conversations are 'only' stored on the servers which participate in a given room and aren't replicated arbitrarily (unlike NNTP, for instance).

To actually secure your conversation, you either need to use application-layer crypto (like PGP or OTR), or wait for us to define our 'official' end-to-end encryption semantics (using something like Axolotl). Obviously proper privacy guarantees are critical to Matrix's success, but whilst we've considered it in the design from day 1, we just haven't implemented it yet.

Seperately from the encryption question we have decentralised ACLs to stop users 'breaking into' private rooms and reading their history, as already discussed. The distinction is between protecting against inappropriate access to private data through legitimate channels (i.e. the Matrix HTTP APIs), which is a relatively hard problem in a decentralised world - and then seperately protecting against inappropriate access to private data through compromised/malicious servers (which is what end2end crypto is for).

Matrix: a new specification for federated realtime chat

Posted Feb 16, 2015 9:16 UTC (Mon) by gmaxwell (guest, #30048) [Link] (1 responses)

I think building a new communications tool which doesn't integrate end to end encryption with the participants -- (even just 'authorized channel users', in the context of channels where participants may be ambiguously defined) is really unwise and maybe even arguably unethical.

> Obviously proper privacy guarantees are critical to Matrix's success

Glad to hear it, but that it isn't in there from day one suggests that you believe that other functionality is more critical. I hope to see improvement in this area.

Matrix: a new specification for federated realtime chat

Posted Feb 16, 2015 9:28 UTC (Mon) by Arathorn (guest, #101018) [Link]

In the end it's a matter of pragmatism. We have designed the whole system to support e2e crypto (i.e. the servers never nake any assumptions about being able to read inside oayloads for routing/filtering/etc) . We just haven't got around to defining the implementation yet. (patches welcome!)

In the end, we want Matrix clients to be as trivial and tiny as possible - eg IoT connected devices talking trivial HTTP. That simply means not mandating HTTPS on the client/server API. Obviously one will be able to define rooms which are E2E only, and then you get best of both worlds.

I sympathise with the idea that "creating an unencrypted protocol in this day and age is unethical". But in the end I also like choice. If you as a user want to mandate crypto (once e2e has landed), you can. And if you as a user want to support lobotomised clients at the expense of privacy, you can too. Everybody wins.

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 22:07 UTC (Thu) by drag (guest, #31333) [Link] (1 responses)

Can you do encrypting messages in the client and just make it very standardized behavior by recommending the clients behave in a particular way?

So say you have something like PGP/GPG on the client side were every message is signed by the user and encrypted using a public key generated for that particular chatroom/session. Then the encrypted messages are naturally stored and replicated just like plain text ones. To 'join' a chatroom then all that is necessary is to accept a invitation from the person/service that created the chatroom which will provide the necessary keys to decrypt previous and new messages.

That way you end up with end-to-end secrecy, the server can continue to manage chat rooms like it normally does. All the messages themselves can be in ascii-armor format or something like that so it wouldn't really change anything. It's just that they would be gibberish to anybody joining the room without a invitation.

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 22:37 UTC (Thu) by Arathorn (guest, #101018) [Link]

Can you do encrypting messages in the client and just make it very standardized behavior by recommending the clients behave in a particular way?

Yup, this is precisely the idea. The catch is that you need to define how users' keys are distributed (PKI using centralised or federated keyservers? or PERSPECTIVEs? or some kind of per-session ephemeral keys? are they ratcheted?); you may need to define the mechanism for securely sharing a symmetric key for the room's content between the participants, or define the strategy for encrypting messages using all the participants keys. Do multiple devices for the same user share the same keys (if so, how?), or is each its own actor? Critically, you need to decide on whether to do PFS or deliberately make past history available to newcomers in the room.

All of this can be done at an application layer layered on top of Matrix (like PGP or OTR implementations on the clients) - but we think it's vital to mandate specific protocols for doing this, to avoid fragmentation and have some hope of ever federating with other e2e crypto systems (e.g. Axolotl-based services such as TextSecure or WhatsApp; or OTR-enabled clients; etc). And we can also provide well-defined helpers in the protocol for handling key discovery/exchange and the other administravia in-band.

We're starting work on this properly next week, so if anyone wants to help define how it works please swing by #matrix:matrix.org and give us a shout!