Messaging Layer Security is coming of age in good news for privacy lovers
It's not finished yet, but MLS being deployed by Wire is good news...
Messaging Layer Security (MLS) has been in gestation for some eight years. A cryptographic key establishment protocol designed to ensure forward secrecy and post-compromise security in group chats, MLS was born over an informal discussion in a Berlin restaurant back in 2016 and grew into an IETF workgroup featuring members from Cisco, Facebook, Google, INRIA, Mozilla, Twitter, and the University of Oxford among others, along with founding member Wire – which has announced that its messenger platform cab now support voice and video calls for up to 100 people, fully end-to-end-encrypted, using MLS in a “first” for a federated environment.
(“Federated” here, meaning between Wire servers: i.e. multiple Wire-server backends that can talk to each other in a way that means User 1 registered on Wire backend A and User 2 registered on Wire backend B can interact with each other as if they belonged to the same backend. Wire admits this is a work in progress.)
Wire’s move is a welcome sign that MLS is emerging into more products and that is, potentially, good news for the democratisation of private messaging at scale: while there is a plethora of end-to-end (E2EE) encrypted messengers out there, E2EE group chat applications face a range of issues: they need to ensure that messages can only be read by members of a given group; they need to be asynchronous (because participants may not be online at the same time); they need to ensure “forward secrecy”: i.e. that full compromise of a node at a point in time does not reveal past messages sent within the group, and ultimately for widespread adoption they need to be scalable to the enterprise level: encryption keys can hog bandwidth and ruin the user experience.
As Joël Alwen, chief cryptographer at messenger Wickr (bought by Amazon in 2021) has noted: "As the secure messaging space grows in complexity and importance, it is becoming ever more important for us to agree on open and thoroughly vetted flexible standards, not to mention an open process for steadily improving on the standard. Especially in terms of the latter, we currently have nothing even close.
"Getting these sorts of things right is really, really hard. (See the history of attacks on Wi-Fi, TLS/SSL, or GSM protocols for examples of just how hard it really is") he added in an earlier blog, that describes MLS purpose as "to produce a practical, well-specified, carefully vetted open standard for federated secure messaging")
In a world of rampant data breaches, rapacious commercial espionage and endlessly prying nation state surveillance actors, having secure conversations without the beady eyes of cybercriminals, rival companies or Big Spook™ all over the content of your enterprise communications is, in short, an attractive – yet still hard to meaningfully attain – proposition and Messaging Layer Security could be a big part of making it happen.
As such, Wire was excited to announce the news, with CTO Alan Duric, one of the founding members of the MLS working group, noting to The Stack that “it’s taken a lot of patience and persistence to get to something deployable. This [protocol] needs to be deployed on billions of devices; there is a number of constraints that you need to think about, from the CPU capacity of those devices where it's going to be running, to the memory allocation for the different cyphers and algorithms that we are using; then thinking also, ‘how is this gonna endure for another 10 to 20 years, because when you are making a protocol and [standard] like this, you need to think at least for the next 10 years and in the next 10 years a post-quantum (world) is likely coming.”
He added: “There was a plethora of issues that needed to be addressed. And I think that the work that has been done is really great, with a number of great contributions from members of the working group – [those] there from Day One, and also some late comers. I think now, as it gets close to the last core draft, and as it gets towards the RFC or Standard status, you're going to see a number of companies joining this effort.”
Messaging Layer Security implementations
There’s various software implementations of MLS out there meanwhile. Wire didn’t disclose details of its own in an initial press release or conversation, although it is expected to share more details anon.
The three that The Stack is aware of include one written by Cisco in C++ primarily intended to meet the needs of Webex and based on an earlier version of MLS; another nascent implementation is OpenMLS, which is written in Rust, based on MLS draft 12 and being built in the open by a team that includes Wire’s former Head of Security Raphael Robert who has the aim of targeting “a larger audience than a single company” and a fairly raw version in TypeScript built by the Matrix team as a testbed for MLS in decentralised environments.
(Matthew Hodgson, CEO, Element and co–founder of Matrix, a decentralised open standard for E2EE communication meanwhile says that rival messenger Element has been working with the IETF working group to ensure that MLS "works well for decentralised (not just federated) communication - as the IETF’s current proposal require there to be a single point of control over conversations, even in a federated environment, in order to keep the sequence of the encryption operations synchronised… we’ve gone a step further and created Decentralized MLS which extends MLS to work in a genuinely decentralized communication environment such as Matrix - ensuring that there is no single point of control or failure over your communication."
He added: "We have this working currently in the labs and it’s looking promising.”
Wire’s Alan Duric told us: “There are basically two different implementations that we are working with that are independent; at this stage, we are not going to be naming them”; he added that more details would follow.
(Wire saw the majority of its security team quit the company in 2021 and has faced some criticism over the approach it has taken to developing its platform as "another walled garden". We're not privy to the reasons for this fall-out in what is perennially a rather fractious world rife with claim and counter-claim (educate us) -- but has been there since the start of the journey as a critical founding member of the IETF working group and deserves credit in The Stack's view for its long-term commitment to MLS, whatever its commercial decisions.)
C2 to C3 -- Hackers phone home using Slack API, queued print jobs
Needless to say, E2EE group messaging is not a simple problem to solve. Cisco notes of its implementation that “setting up a secret key among a group when the group only has access to an untrusted channel seems magical. Techniques for doing this were first developed in the 1980s, and today, more than 90 percent of web browsing uses Transport Security Layer (TLS) to do exactly this. MLS extends this functionality to groups (TLS only works point to point), so we can use it to set up conference keys, even when the conference provider is untrusted”.
"In an MLS-secured group chat, when a new participant wants to join the meeting, they ask to be let in by sending an MLS KeyPackage message to the leader, which provides their public key and authentication information.
"The leader responds with a Welcome message that tells the joiner about the other participants in the meeting. The leader also broadcasts an Add message and a Commit message to the group. The Add message announces the new joiner to those already in the meeting. The Commit message causes all the current participants to hash the old group key to get a new key for the now-extended group; the Welcome message provides this key to the joiner” while when someone leaves, the randomly designated leader broadcasts MLS Remove and Commit messages to everyone remaining: “The Remove message tells the remaining participants who left and the Commit encrypts a new key to all the remaining participants.. The remaining participants hash the new key with the old group key to get a key that the leaver doesn’t have... After each rotation, the participants in the meeting delete their copies of the old keys so that even if one of them is compromised, the old meeting content is safe. Finally, at the end of the meeting, the participants delete any remaining keys, so that even if the content of the E2E meeting was stored somewhere, it can no longer be decrypted. Key rotation can mean that it takes a couple of extra seconds to join a meeting or kick someone out, but it gives clear security assurance: If someone doesn’t appear in the participant list for the meeting, they don’t have the keys to decrypt the content.
When it comes to the encryption itself, MLS is agnostic, within reason. The draft IETF protocol notes that "it is advisable to keep the number of ciphersuites low to increase the chances clients can interoperate in a federated environment, therefore the ciphersuites only inlcude modern, yet well-established algorithms."
It adds: "Depending on their requirements, clients can choose between two security levels (roughly 128-bit and 256-bit). Within the security levels clients can choose between faster X25519/X448 curves and FIPS 140-2 compliant curves for Diffie-Hellman key negotiations. Additionally clients that run predominantly on mobileprocessors can choose ChaCha20Poly1305 over AES-GCM for performance reasons. Since ChaCha20Poly1305 is not listed by FIPS 140-2 it is not paired with FIPS 140-2 compliant curves. The security level of symmetric encryption algorithms and hash functions is paired with the security level of the curves. The mandatory-to-implement ciphersuite for MLS 1.0 is MLS10_128_DHKEMX25519_AES128GCM_SHA256_Ed25519 which uses Curve25519 for key exchange, AES-128-GCM for HPKE, HKDF over SHA2-256, and Ed25519 for signatures."
Strong views on the development of Messaging Layer Security? Did we get something wrong? Yell at us over plaintext here or reach us securely on Telegram here /s
