@stillgreenmoss@social.coop @ben @delta @besendorf The RFC was rather recent and I'm not aware of any end-user apps at this point.
@crepererum @stillgreenmoss @ben @besendorf OpenMLS is an almost decade- long effort with the IETF work starting in 2018. We have studied it and are following developments but one known big issue is its dependency on "total message ordering" which can not be easily obtained in federated settings. Several people, including Matrix folks, have tried to remedy it but we do not know of any practical solution to make OpenMLS work reasonably well for non-centralised settings.
@delta @stillgreenmoss@social.coop @ben @besendorf I wonder what @raphaelrobert 's PoV is here. Are there plans to lift "total message ordering" requirement?
@crepererum @delta @stillgreenmoss @ben @besendorf I can say that MLS works well in a federated environment. Federation has always been part of the picture during the design phase. The fact it doesn’t work in Matrix yet is a Matrix problem, not an MLS problem. MLS is part of the (newish) federated MIMI spec and it also works in our stack. Of course it’s still early days for MLS, but it’s already deployed by e.g. Cisco Webex.
@raphaelrobert @crepererum @stillgreenmoss @ben @besendorf the DCGKA paper https://eprint.iacr.org/2020/1281 also states that total message ordering is required with MLS. Could you point to docs/code underlying the claim that MLS now practically works in decentralized/federated environments with mixed offline/online usage patterns?
@delta @crepererum @stillgreenmoss @ben @besendorf
The following sections from the MLS architecture document shed some light on that:
- https://www.ietf.org/archive/id/draft-ietf-mls-architecture-13.html#name-federation
- https://www.ietf.org/archive/id/draft-ietf-mls-architecture-13.html#name-delivery-of-messages
Commit messages need to be ordered indeed, normal E2EE application messages need not be ordered. That being said MLS is not a drop-in replacement for email encryption, it requires a Delivery Service. But for typical messaging and/or video conferencing systems, it works well in federated environments.
@raphaelrobert @crepererum @stillgreenmoss @ben @besendorf if group member add/remove messages (particularly common in large groups) need to be ordered this is a barrier to adoption in federated settings even if chat/app messages themselves don't need to be ordered.
@delta @crepererum @stillgreenmoss @ben @besendorf Any messaging system needs some ordering eventually, because it matters whether or not e.g. Alice is in the group when a message is encrypted. It also matters what order users see in a group chat. This is true for Matrix, MLS and other protocols. If you read up a bit on how a Delivery Service can work, you'll see there's a variant that's "eventually consistent" and allows you to do the ordering at any point in time.
@delta @crepererum @stillgreenmoss @ben @besendorf
And this is the MIMI WG, where we work on federated messaging and video conferencing, based on MLS: https://datatracker.ietf.org/group/mimi/about/
@rakoo @besendorf @delta @ben @raphaelrobert @stillgreenmoss@social.coop
If you "eventually" converge to a group membership state, you'll send messages to an inconsistent group in the meantime. This means:
a) some people may not receive or be able to decrypt your message
b) you may leak data to people that got removed from the group
While A is bad UX, B is certainly a security risk in some scenarios.
@crepererum @rakoo @besendorf @delta @ben @stillgreenmoss
In that scenario, you would send a message to the people who are in *your* view of the group. It's not deceitful to users and might still be an acceptable UX. But obviously the "strongly consistent" variant is the preferred one and should be used whenever the architecture allows it. That's also what MIMI intends to do.
@raphaelrobert @crepererum @rakoo @besendorf @ben @stillgreenmoss we operate on a <1/100 fraction of the money that signal, matrix, wa or telegram use and we just completed major security milestones, have a reliable base for guaranteed end-to-end encryption now, including multi-device, cross-platform and offline first operations. OpenMLS is quite far from a low hanging fruit in our case and we would first like to see one of the aforementioned messengers adopting it. #realism
@delta @raphaelrobert @crepererum @rakoo @besendorf @stillgreenmoss Keep it real! Abandoning Autocrypt would be a huge mistake for the project. Delta Chat is stable, mature, and developed. Changing fundamental design features at this point should not be done at all, or done with absolute caution. Delta Chat has been audited for security. Don't fix what isn't broken!
@delta @crepererum @rakoo @besendorf @ben @stillgreenmoss it sounds like Delta Chat is in a good place! I have no idea if MLS is a good fit for it, I just maintain that it was specifically developed to offer good FS & PCS while being efficient and federation-friendly.
@raphaelrobert @crepererum @rakoo @besendorf @ben @stillgreenmoss it's appreciated and that's why we are following developments around MLS. While most people think that developments or protocols happen fast, they in fact often take many years to evolve. WhatsApp, signal, telegram, matrix are all decade+ running projects and there are in fact not so many people working at the more fundamental levels of these efforts. Thanks for your work, our comments were not meant to disparage!
@delta @raphaelrobert @rakoo @besendorf @ben @stillgreenmoss@social.coop Thanks to both sides of the discussion. I've learned a lot from the arguments and PoVs