mastodon.online is one of the many independent Mastodon servers you can use to participate in the fediverse.
A newer server operated by the Mastodon gGmbH non-profit

Server stats:

11K
active users

crepererum

@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 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:
- ietf.org/archive/id/draft-ietf
- ietf.org/archive/id/draft-ietf
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.

www.ietf.orgThe Messaging Layer Security (MLS) Architecture The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-protocol) provides a Group Key Agreement protocol for messaging applications. MLS is meant to protect against eavesdropping, tampering, message forgery, and provide Forward Secrecy (FS) and Post-Compromise Security (PCS). This document describes the architecture for using MLS in a general secure group messaging infrastructure and defines the security goals for MLS. It provides guidance on building a group messaging system and discusses security and privacy tradeoffs offered by multiple security mechanisms that are part of the MLS protocol (e.g., frequency of public encryption key rotation). The document also provides guidance for parts of the infrastructure that are not standardized by MLS and are instead left to the application. While the recommendations of this document are not mandatory to follow in order to interoperate at the protocol level, they affect the overall security guarantees that are achieved by a messaging application. This is especially true in the case of active adversaries that are able to compromise clients, the delivery service, or the authentication service.

@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

If the messages to be linearized are strictly "group member add/remove" then it might be possible to formalize them and use some distributed systems academia stuff to make it work. One such system is Bayou, where you define operations that are reversible, eventually synchronize them all, and on conflicts know what to do (a double add of the same contact results in a single add, for example).

There is a simplified implementation of these ideas in aerogramme (see https://aerogramme.deuxfleurs.fr/documentation/internals/log/), an IMAP server that works over distributed S3-like nodes, so they had to implement this: adding/removing emails/flags without conflicts, with a trick to not duplicate UIDs. Perhaps deltachat can use this to implement MLS ?

(I have no idea how far you've studied the situation, sorry if this is all obvious0
@raphaelrobert @crepererum @stillgreenmoss @ben @besendorf
aerogramme.deuxfleurs.fr Mutation log | Aerogramme An open-source distributed storage service you can self-host to fullfill many needs.

@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 🙂

@raphaelrobert

Unfortunately no. If there are 3 peers A, B, C and B needs to be evicted, I (A) will send a peer remove message. But maybe C won't receive it, and will send a message to the whole group, including B, before receiving my peer remove message.
@crepererum @besendorf @delta @ben @stillgreenmoss
@crepererum

Yep, that's distributed systems. Using a centralization point is not a solution, a compromise has to be made, much like choosing to not be able to see the history in Signal is a compromise. MLS reduces it by demanding that each peer periodically renews their key so that peers that are disconnected for too long are removed (not necessarily nice, but gives a maximum window of compromise)

Nothing's perfect, but the first thing is to evaluate the thread model before waiting for the perfect solution.
@besendorf @delta @ben @raphaelrobert @stillgreenmoss