IETF MLS (<a href="https://datatracker.ietf.org/wg/mls/about/" rel="nofollow">https://datatracker.ietf.org/wg/mls/about/</a>) was ratified in September 2022 by messenger service vendors (including Wire, Matrix, Mozilla, Cisco, Google, Facebook), who have been working for several years on an E2EE group messaging protocol to live alongside TLS. MLS is already deployed in production by Cisco WebEx.<p><i>> Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands.</i><p>There is now a follow-up IETF project to use MLS for inter-messenger interoperability, with Matrix as an early participant, <a href="https://news.ycombinator.com/item?id=33420112" rel="nofollow">https://news.ycombinator.com/item?id=33420112</a><p>Review of 2020 draft protocol, <a href="https://liu.diva-portal.org/smash/get/diva2:1388449/FULLTEXT01.pdf" rel="nofollow">https://liu.diva-portal.org/smash/get/diva2:1388449/FULLTEXT...</a><p><i>> Work is now ongoing to introduce the Messaging Layer Security (MLS) protocol as an efficient standard with high security guarantees for messaging in big groups. This thesis examines whether current MLS implementations live up to the promised performance properties and compares them to the popular Signal protocol. In general the performance results of MLS are promising and in line with expectations, providing improved performance compared to the Signal protocol as group sizes increase.</i>
How is twitter intending to use libsignal? I doubt it would be via the primary AGPL license[1], forcing them to publish the source code of their backend service. Does signal sell private licenses?<p>[1] <a href="https://github.com/signalapp/libsignal/blob/main/LICENSE" rel="nofollow">https://github.com/signalapp/libsignal/blob/main/LICENSE</a>
A timely reminder of the non-cryptographic issues you must get right, in addition to the cryptographic ones, in order to build a robustly secured system!
Encryption's always hard to get right, so it honestly doesn't surprise me that libsignal isn't enough. Though I've never had good experience with libsignal
Seems like the author has an axe to grind.<p>> When you want to send a message to someone, you ask the server for one of their one-time prekeys and use that. Decrypting this message requires using the private half of the one-time prekey, and the recipient deletes it afterwards. This means that an attacker who intercepts a bunch of encrypted messages over the network and then later somehow obtains the long-term keys still won't be able to decrypt the messages, since they depended on keys that no longer exist.<p>> Since these one-time prekeys are only supposed to be used once (it's in the name!) there's a risk that they can all be consumed before they're replenished. The spec regarding pre-keys says that servers should consider rate-limiting this, but the protocol also supports falling back to just not using one-time prekeys if they're exhausted (you lose the forward secrecy benefits, but it's still end-to-end encrypted).<p>> This implementation not only implemented no rate-limiting, making it easy to exhaust the one-time prekeys, it then also failed to fall back to running without them. Another easy way to force DoS.<p>You just described a security/convenience tradeoff in the use of prekeys. OK. Then, the app's choice to go with security over convenience is a security problem, because you're not allowed to send messages without forward secrecy. For greater security, the app should have allowed messages at a lower level of security.<p>If you want to make the case that someone did the wrong thing, do it in a way where they wouldn't also have been wrong if they did the opposite of what you're complaining about.