<a href="https://www.ietf.org/blog/support-for-mls-2023/" rel="nofollow noreferrer">https://www.ietf.org/blog/support-for-mls-2023/</a><p><pre><code> [AWS] Since the early days of MLS, AWS has been a core contributor by sharing our cryptographic expertise and engineering experience.
[Cisco] supported the Messaging Layer Security (MLS) effort since its inception — including by using a draft version of MLS for Webex Zero Trust meetings — and are delighted to welcome the publication of the MLS protocol standard.
[Cloudflare] With MLS, we see a future where large-scale, dynamic group communication can be private, secure, and efficient. We are eager to support and adopt this promising new standard.
[Google/Android] With seven years of development, MLS is mature and rigorously validated, making it the ideal choice to provide the security foundations of interoperable messaging."
[Matrix] With other interested parties, we’re continuing to develop decentralized best practices for MLS (so-called Decentralized MLS) that will work without modification in a decentralized environment such as Matrix or IETF’s MIMI
[Meta] conducted early research into Ratchet Trees alongside collaborators from Oxford University.
[Mozilla] Although end-to-end encryption is at the heart of this initiative, interoperability, scalability, and performance were significant goals met along the way. Mozilla is proud to support this new standard.
[Wire] Previously, technologies like Voice-over-IP and WebRTC played a significant role in democratizing global communication. Now, with MLS, we are building upon this success to again impact billions of people and achieve secure communication at an unprecedented scale.</code></pre>
Security, Cryptography, Whatever did a good general overview of the spec a couple of months ago: <a href="https://securitycryptographywhatever.com/2023/04/22/mls/" rel="nofollow noreferrer">https://securitycryptographywhatever.com/2023/04/22/mls/</a>
From <a href="https://simplex.chat/blog/20230722-simplex-chat-v5-2-message-delivery-receipts.html" rel="nofollow noreferrer">https://simplex.chat/blog/20230722-simplex-chat-v5-2-message...</a><p>>Why not hosted groups with MLS?<p>>Initially, we considered the design with the dedicated servers, potentially self-hosted, that host groups. This design would require adopting MLS (or similar) protocol for group-wide key agreement. Unfortunately, this design is not sufficiently resilient and easier to censor than decentralized design. Also, MLS protocol is very complex to implement, requires a centralized component, and reduces forward secrecy. So we decided against this approach.
This has been discussed recently [1] in another post.<p>[1] <a href="https://news.ycombinator.com/item?id=36815705">https://news.ycombinator.com/item?id=36815705</a> (4 days ago, 202 points, 32 comments)
There's an open source implementation at <a href="https://openmls.tech/" rel="nofollow noreferrer">https://openmls.tech/</a>
Another win for djb for a fully rigid curve[1] required for the single mandatory cipher suite MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519<p>[1] <a href="https://safecurves.cr.yp.to/rigid.html" rel="nofollow noreferrer">https://safecurves.cr.yp.to/rigid.html</a>
I like the idea conceptually, but what is the likelihood of broader adoption? I notice that Meta, Apple, and Google are conspicuously absent from the contributors. Historically (see e.g. Matter) it seems like standards that aren't written to conform to existing de facto implementations tend to be superseded by later ones that are.<p>I'll admit to not having read the entirety of the RFC, but I'd also be curious about how the proposed approach maps to the current privacy/UX goals that the established players are pursuing, e.g. if WhatsApp wants to preserve cleartext moderation of E2E group chats, is that possible under this scheme, etc.
What is Moxie Marlinspike's take on this? I don't trust that an IETF task force is going to have the will to oppose government pressure for backdoors.
This past weekend I was trying to solve a similar problem also with shared public keys. I was having trouble getting it to work for my needs the way I wanted, so instead I am testing an approach of using large hash comparison based upon a preshared key. It’s a much higher grade of cryptographic reliability at a tiny fraction of the computational cost with many fewer parts to maintain.
Encrypted messages in large groups is such a hard problem, and, not to be crass, but is it worth solving? If I have 287 people on a group chat, how is that private, no matter the security? It seems like any adversary should be able to insert themselves into a situation like that unnoticed.
Why are they using MLS to describe this? That acronym has already been widely used.<p><a href="https://en.wikipedia.org/wiki/Multilevel_security" rel="nofollow noreferrer">https://en.wikipedia.org/wiki/Multilevel_security</a><p><a href="https://csrc.nist.gov/glossary/term/multi_level_security" rel="nofollow noreferrer">https://csrc.nist.gov/glossary/term/multi_level_security</a><p><a href="https://gdmissionsystems.com/multilevel-security" rel="nofollow noreferrer">https://gdmissionsystems.com/multilevel-security</a><p><a href="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security-enhanced_linux/mls" rel="nofollow noreferrer">https://access.redhat.com/documentation/en-us/red_hat_enterp...</a><p><a href="https://www.ibm.com/docs/SSLTBW_2.3.0/com.ibm.zos.v2r3.e0ze100/ch1.htm" rel="nofollow noreferrer">https://www.ibm.com/docs/SSLTBW_2.3.0/com.ibm.zos.v2r3.e0ze1...</a>