5 ms·

I hope MLS will support a decentralized messaging system, which will be required for interoperable systems with no central authority like the Matrix network. O

I hope MLS will support a decentralized messaging system, which will be required for interoperable systems with no central authority like the Matrix network. Originally it didn't[0], I hope this has changed or will. Otherwise, I'd guess it would be dead on arrival. [0] https://matrix.uhoreg.ca/mls/decentralised.html https://matrix.uhoreg.ca/mls/decentralised.html

walterbell 4y ago
Interoperability work on top of MLS is underway. Edit: see https://news.ycombinator.com/item?id=35366250 https://news.ycombinator.com/item?id=35366250 for audio. https://datatracker.ietf.org/doc/bofreq-cooper-more-instant-messaging-interoperability/ https://datatracker.ietf.org/doc/bofreq-cooper-more-instant-... & https://news.ycombinator.com/item?id=33420112 https://news.ycombinator.com/item?id=33420112 > The IETF had multiple prior lines of effort in this area during the development and widespread deployment of XMPP and SIP decades ago, but the nature of existing messaging implementations and the external environment have both changed significantly since then. Messaging applications now share more common content features and functionality, the MLS protocol has been developed to facilitate E2EE interoperable messaging, and regulatory pressure to interoperate has increased significantly (e.g., as a result of the EU Digital Markets Act). https://mailarchive.ietf.org/arch/msg/mimi/CI3z3CUPE8rrC5p4_ysJYY7ELD4/ https://mailarchive.ietf.org/arch/msg/mimi/CI3z3CUPE8rrC5p4_... & https://techcrunch.com/2022/12/30/inside-matrix-the-protocol-that-might-finally-make-messaging-apps-interoperable/ https://techcrunch.com/2022/12/30/inside-matrix-the-protocol... > We sometimes found that the various components of Matrix came together in unexpected ways that created problems, even if they were fine in isolation. From our reading of the charter and current drafts, it is likely that MIMI will need to include new cryptographic protocols (or integrate existing ones). As such, an analysis that looks at how the pieces of the puzzle fit together would be valuable. Thus, we'd like to advocate for following the path of MLS and TLS 1.3 by engaging the security, privacy, cryptography and formal verification communities.
ianopolous 4y ago
As your link discusses, MLS still requires centralization because of the requirements of total ordering of some messages by the delivery service. If you want a truly p2p encrypted group chat protocol then look at DCGKA by Matthew Weidner, Martin Kleppmann et al: https://dl.acm.org/doi/10.1145/3460120.3484542 https://dl.acm.org/doi/10.1145/3460120.3484542
- deleted 4y ago
  [deleted]
- tcfhgj 4y ago
  the link was updated in 2021
  - ianopolous 4y ago
    And it's still true today. I was considering implementing MLS myself, but decided against it because of this. https://github.com/mlswg/mls-architecture/blob/main/draft-ietf-mls-architecture.md#delivery-of-messages-delivery-guarantees https://github.com/mlswg/mls-architecture/blob/main/draft-ie...
    - tcfhgj 4y ago
      Sad
- 0ptix 4y ago
  DCGKA has O(n) complexity, so more like Signal groups than MLS. Here's a version of MLS (By Alwen, Mularczyk, Tselekounis) which supports out order delivery of commits. https://eprint.iacr.org/2023/394 https://eprint.iacr.org/2023/394
  - ianopolous 4y ago
    That's true, but not really relevant until you hit 1000s of chat members. MLS targets up to 50,000. But there isn't a plausible threat model for a secure chat that large (someone will leak or it will be infiltrated).
    - kitkat_new 4y ago
      it's already relevant at 1000 members, and why not use it when it is possible? Also, switch messenger once you hit 1k? Even it a leak may be possible, it still isn't guaranteed. Instead you guarantee server side access without e2ee

walterbell 4y ago

Interoperability work on top of MLS is underway. Edit: see https://news.ycombinator.com/item?id=35366250 https://news.ycombinator.com/item?id=35366250 for audio. https://datatracker.ietf.org/doc/bofreq-cooper-more-instant-messaging-interoperability/ https://datatracker.ietf.org/doc/bofreq-cooper-more-instant-... & https://news.ycombinator.com/item?id=33420112 https://news.ycombinator.com/item?id=33420112 > The IETF had multiple prior lines of effort in this area during the development and widespread deployment of XMPP and SIP decades ago, but the nature of existing messaging implementations and the external environment have both changed significantly since then. Messaging applications now share more common content features and functionality, the MLS protocol has been developed to facilitate E2EE interoperable messaging, and regulatory pressure to interoperate has increased significantly (e.g., as a result of the EU Digital Markets Act). https://mailarchive.ietf.org/arch/msg/mimi/CI3z3CUPE8rrC5p4_ysJYY7ELD4/ https://mailarchive.ietf.org/arch/msg/mimi/CI3z3CUPE8rrC5p4_... & https://techcrunch.com/2022/12/30/inside-matrix-the-protocol-that-might-finally-make-messaging-apps-interoperable/ https://techcrunch.com/2022/12/30/inside-matrix-the-protocol... > We sometimes found that the various components of Matrix came together in unexpected ways that created problems, even if they were fine in isolation. From our reading of the charter and current drafts, it is likely that MIMI will need to include new cryptographic protocols (or integrate existing ones). As such, an analysis that looks at how the pieces of the puzzle fit together would be valuable. Thus, we'd like to advocate for following the path of MLS and TLS 1.3 by engaging the security, privacy, cryptography and formal verification communities.

ianopolous 4y ago

As your link discusses, MLS still requires centralization because of the requirements of total ordering of some messages by the delivery service. If you want a truly p2p encrypted group chat protocol then look at DCGKA by Matthew Weidner, Martin Kleppmann et al: https://dl.acm.org/doi/10.1145/3460120.3484542 https://dl.acm.org/doi/10.1145/3460120.3484542

deleted 4y ago
[deleted]
tcfhgj 4y ago
the link was updated in 2021
- ianopolous 4y ago
  And it's still true today. I was considering implementing MLS myself, but decided against it because of this. https://github.com/mlswg/mls-architecture/blob/main/draft-ietf-mls-architecture.md#delivery-of-messages-delivery-guarantees https://github.com/mlswg/mls-architecture/blob/main/draft-ie...
  - tcfhgj 4y ago
    Sad
0ptix 4y ago
DCGKA has O(n) complexity, so more like Signal groups than MLS. Here's a version of MLS (By Alwen, Mularczyk, Tselekounis) which supports out order delivery of commits. https://eprint.iacr.org/2023/394 https://eprint.iacr.org/2023/394
- ianopolous 4y ago
  That's true, but not really relevant until you hit 1000s of chat members. MLS targets up to 50,000. But there isn't a plausible threat model for a secure chat that large (someone will leak or it will be infiltrated).
  - kitkat_new 4y ago
    it's already relevant at 1000 members, and why not use it when it is possible? Also, switch messenger once you hit 1k? Even it a leak may be possible, it still isn't guaranteed. Instead you guarantee server side access without e2ee