Messaging Layer Security (MLS) #35
Conversation
|
Submitted as-is per request from @martinthomson |
There was a problem hiding this comment.
Hi Ben,
Couple of content fixes / sections I'd like to see before landing this.
- Can you add a one-sentence summary of the user-problem that is being addressed in the Problem statement? The current description jumps directly into a protocol level problem and lacks that context.
- Can you add sections 2-5 described in https://github.com/mozilla/explainers?tab=readme-ov-file#explainer-sections before your "Proposal" section which should be section 6?
Thanks
|
|
||
| ### Problem statement | ||
|
|
||
| For the longest time, due to the lack of technology, pairwise channels were used |
There was a problem hiding this comment.
Maybe this could be punchier.
Key agreement is very challenging to build.
Without better tools, like MLS,
applications often attempt to build a system
based on pairwise channels.
This is both grossly inefficient ($\mathcal{O}(N^2)$)
and it frequently fails to achieve the expected
security goals for group key agreement.MLS provides an efficient protocol
that has extensive security analysis.
Implementing MLS is non-trivial,
which makes a standard implementation appealing.Making MLS available makes it possible
to build secure group communication into a range of applications,
including messaging, video conferencing, cloud storage, and more.
| Messaging Layer Security (MLS) (RFC 9420) provides convenient and secure | ||
| ***Continuous Group Key Agreement (CGKA) for dynamic groups***, ranging from one | ||
| to hundreds of thousands of participants. | ||
|
|
||
| The MLS API provides applications with two main capabilities: | ||
|
|
||
| * Group management: applications can manage the participation of different | ||
| * entities, including the current browser, in groups. | ||
|
|
||
| * Secure messaging: once | ||
| * created, a group generates a shared secret that can be used to provide | ||
| * end-to-end protected messaging with group participants. | ||
|
|
||
| This explainer outlines the goals, design, and potential use cases of the API. |
There was a problem hiding this comment.
Again, shorter might be good.
Provide a simplified MLS API for web applications.
This includes basic functions for group management,
such as adding and removing members.
For groups, both secure messaging using the internal MLS key schedule
and exporting of keying material for more advanced applications is possible.
| ### Goals | ||
|
|
||
| 1. **Provide a Continuous Group Key Agreement**: We want to enable Web and | ||
| Internet applications to use MLS as a way to build and manage groups using its | ||
| secure group key establishment directly from the browser, in particular for | ||
| End-to-End Encrypted applications. | ||
|
|
||
| 2. **State-of-the-Art Security**: Manipulate sensitive values and cryptographic | ||
| secrets of the protocol natively instead of exposing them to the web | ||
| application. Shipping an up-to-date MLS library which removes the need for | ||
| application developers to have a dedicated evaluation and software lifecycle for | ||
| this critical component. Similar to TLS, QUIC or WebRTC, ensure to provide a | ||
| high quality implementation to users. | ||
|
|
||
| 3. **Privacy and avoid user tracking**: Prevent user tracking by using | ||
| traditional techniques of partitioning the MLS state by origin. This will ensure | ||
| that strong identifiers like public keys are not reused across sites. | ||
|
|
||
| 4. **Ensure Performance**: Avoid back and forth between JavaScript, C++, storage | ||
| and cryptographic computations. Handle everything natively within browser native | ||
| code. |
There was a problem hiding this comment.
I don't think that we need this section in the explainer. The proposal covers the point 1. The other points should be implied.
| 2. **Guarantee full interoperability across applications**: We cannot force that | ||
| different applications are interoperable, especially in a federated | ||
| context. However if service providers decide to agree on interoperability at the | ||
| application level by defining coherent MLS group and client configurations, the | ||
| MLS layer messages will be interoperable and applications will be able to build | ||
| a shared group. |
There was a problem hiding this comment.
I think that this is a corollary of the first point. I would remove this one and keep the other.
| ### How do I enable the experiment ? | ||
|
|
||
| **Navigate to \`about:config\` and set \`security.mls.enabled\` to \`true\`.** |
There was a problem hiding this comment.
An explainer for a specification won't have this longer term. I would move this right to the bottom and mention Firefox explicitly.
| let pt1 = await ga.receive(ctx1) | ||
| ``` | ||
|
|
||
| ### Prototype WebIDL Definition |
There was a problem hiding this comment.
It might pay to move this out of the explainer. It's a lot to process without accompanying documentation.
| ### Ongoing work | ||
|
|
||
| - Alignment with other platforms such as Android | ||
| - Web Application Integrity, Consistency and Transparency effort | ||
| - Interaction with WebRTC \+ SFrame / MLS | ||
| - Get feedback to be in a good shape before submitting to standardization |
There was a problem hiding this comment.
These can be cut from the explainer.
| - We will have to decide about an improved UX and UI for the long state storage, | ||
| and the permissions to add and clear state. |
There was a problem hiding this comment.
Not necessary to include in an explainer.
| - Consider and discuss the idea of migrating the management of MLS cryptographic | ||
| keys to the Credential Manager. | ||
|
|
||
| ### Conclusion |
There was a problem hiding this comment.
Explainers don't need conclusions.
Like many specifications, you should include some of the more interesting consequences of the design choices. I can't think of many things, but you might include:
- A description of how you expect groups to be stored and how (if at all) applications might manage that storage.
- A discussion of how this might interact with WebCrypto (including whether secret keys can be made readable).
- Notes on extensibility.
Feel free to make these a "TODO" or follow up in issues rather than having them inline.
| - Consider and discuss the idea of migrating the management of MLS cryptographic | ||
| keys to the Credential Manager. |
There was a problem hiding this comment.
This smells Firefox-specific.
No description provided.