9 ms·

The Messaging Layer Security (MLS) Protocol

134 points by Sami_Lehtinen 6y ago

miohtama 6y ago
For a layman, does this solve the end-to-end encrypted group chat problem?
- rhencke 6y ago
  > Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands.
- sylvain_kerkour 6y ago
  It solves the scalability issues of current generation key distribution algorithms. In my opinion the best article about it is: https://blog.trailofbits.com/2019/08/06/better-encrypted-group-chat https://blog.trailofbits.com/2019/08/06/better-encrypted-gro...
- wdb 6y ago
  You would think this problem is already solved as it’s a similar problem when navy ships from different countries need to communicate then they need to communicate keys too and ships can be added or removed from the group. For example, Joining a (n,n)-signature schema without a trusted third party.
  - baby 6y ago
    Now increase that by orders of magnitude and you need a new protocol due to efficiency reasons. Things don’t always scale well.
- xbar 6y ago
  It also solves the post-compromise eavesdropping problem.
kitkat_new 6y ago
I have heard it does not support decentralized services as it requires a central entity?
- mprdev 6y ago
  There is a discussion on client-ordered state updates, but the implementation is outside of the protocol's scope. There is no requirement for a centralized service so long as you find an agreeable resolution strategy for conflicts. One that works from a user's perspective as well.
- feanaro 6y ago
  Some Wire and Matrix people are working towards a decentralized MLS proposal, last I heard.
  - Arathorn 6y ago
    yup, we’re working on Decentralised MLS for Matrix. Wire have something going on too.
saurik 6y ago
I find the most interesting discussions surrounding this protocol are about whether or not it should support deniability / repudiation of messages. The Off-The-Record messaging people--including specifically Ian Goldberg--were unhappy that this was a non-goal, and the reasoning on the mailing list at the time was frustrating (that deniability can be used by "terrorists" to dodge investigations); but, I have also seen them have better arguments on their issue tracker (about power imbalances... though this argument was also controversial). https://mailarchive.ietf.org/arch/msg/mls/ZJ4e78obXSdYWnxmsNUqGc_qe68/ https://mailarchive.ietf.org/arch/msg/mls/ZJ4e78obXSdYWnxmsN... https://github.com/mlswg/mls-architecture/issues/50 https://github.com/mlswg/mls-architecture/issues/50
- baby 6y ago
  I don’t think deniability is an interesting property honestly, I’d be much more interested in a protocol that protects against insider attacks (e.g. there is no transcript consistency, you can send some messages to some participants and some messages to others)
  - earthboundkid 6y ago
    Deniability is in the news now with the Hunter Biden emails. If you steal a bunch of emails, they’re only useful as blackmail if they’re not deniable. If there’s deniability, the would be blackmail victim can just say that the emails are fake and it’s he said/she said. It lowers the incentives for stealing emails.
    - crankyoldcrank 6y ago
      Don't worry, those emails are pretty much already down the memory hole.
  - lucb1e 6y ago
    +1. What even is the use-case for plausible deniability? The way I heard it, is if your conversational partner is from the FBI and you want to whistleblow something, the plausible deniability can be used to plausibly deny that you said something to the agent. But who's the judge going to believe: the agent that claimed message X was sent to them, or the user who said that the agent must have forged message X? Heck, if the government is that suspicious of someone they can also order the ISP to setup a tap and see that the right number of bytes at the right time were sent. The feature requires extra complexity in security protocols, plus might give people a false sense that they can just deny anything afterwards when that is not the case. Checking Wikipedia to make sure I understand the point correctly, it claims it's more about denying that encryption was used at all (good luck with that one in an encrypted chat) or that there can be multiple plaintexts (so you can later come up with a completely different chat log, lying in court and claiming the other party has forged everything, which has the same issue as above). Transcript consistency on the other hand seems to me like an expected feature for any >2010 multi-party encryption protocol. That can be practically used to change the conversation shown to a third participant (taking a "yes" of mine from one place, pasting it elsewhere while withholding the original reply...).
ViViDboarder 6y ago
I’m not sure how exact to read this, but I’m curious how it differs from the Signal protocol.
- baby 6y ago
  Signal doesn’t really address group chat, or it does but in some very limited ways that won’t scale passed a lot of participants (depending which group chat protocol you use among the different ones that have been implemented with the Signal protocol). Now if you ask me why you would want end-to-end encryption in a group with hundreds, thousands, or more users I have no answer for you. IMO group chat passed 30 users should revert to public group chats instead of giving you a false sense of privacy.
  - some_furry 6y ago
    > IMO group chat passed 30 users should revert to public group chats instead of giving you a false sense of privacy. Whether or not that's a "false" sense of privacy depends on your threat model. Is your primary threat "What if someone hacks the communication server and leaks our conversations?" (This is something I worry about a lot.) Is your primary threat "What if someone in our chat is a spy and we're planning crimes?" (This is something I don't worry about, but others might.) In the first case, E2EE for up to 1000 participants in a group still makes sense. In the second case, every additional participant is additional liability of government subversion.
motohagiography 6y ago
Oddly, I do work reasoning about security protocols and the notations in this still seem opaque. The trail of bits article has some standard notation in it in their cartoons, but both seem to jump between levels of abstraction. Does anyone pay to have these things described clearly?

134 points by Sami_Lehtinen 6y ago

miohtama 6y ago

For a layman, does this solve the end-to-end encrypted group chat problem?

rhencke 6y ago
> Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands.
sylvain_kerkour 6y ago
It solves the scalability issues of current generation key distribution algorithms. In my opinion the best article about it is: https://blog.trailofbits.com/2019/08/06/better-encrypted-group-chat https://blog.trailofbits.com/2019/08/06/better-encrypted-gro...
wdb 6y ago
You would think this problem is already solved as it’s a similar problem when navy ships from different countries need to communicate then they need to communicate keys too and ships can be added or removed from the group. For example, Joining a (n,n)-signature schema without a trusted third party.
- baby 6y ago
  Now increase that by orders of magnitude and you need a new protocol due to efficiency reasons. Things don’t always scale well.
xbar 6y ago
It also solves the post-compromise eavesdropping problem.

kitkat_new 6y ago

I have heard it does not support decentralized services as it requires a central entity?

mprdev 6y ago
There is a discussion on client-ordered state updates, but the implementation is outside of the protocol's scope. There is no requirement for a centralized service so long as you find an agreeable resolution strategy for conflicts. One that works from a user's perspective as well.
feanaro 6y ago
Some Wire and Matrix people are working towards a decentralized MLS proposal, last I heard.
- Arathorn 6y ago
  yup, we’re working on Decentralised MLS for Matrix. Wire have something going on too.

saurik 6y ago

I find the most interesting discussions surrounding this protocol are about whether or not it should support deniability / repudiation of messages. The Off-The-Record messaging people--including specifically Ian Goldberg--were unhappy that this was a non-goal, and the reasoning on the mailing list at the time was frustrating (that deniability can be used by "terrorists" to dodge investigations); but, I have also seen them have better arguments on their issue tracker (about power imbalances... though this argument was also controversial). https://mailarchive.ietf.org/arch/msg/mls/ZJ4e78obXSdYWnxmsNUqGc_qe68/ https://mailarchive.ietf.org/arch/msg/mls/ZJ4e78obXSdYWnxmsN... https://github.com/mlswg/mls-architecture/issues/50 https://github.com/mlswg/mls-architecture/issues/50

baby 6y ago
I don’t think deniability is an interesting property honestly, I’d be much more interested in a protocol that protects against insider attacks (e.g. there is no transcript consistency, you can send some messages to some participants and some messages to others)
- earthboundkid 6y ago
  Deniability is in the news now with the Hunter Biden emails. If you steal a bunch of emails, they’re only useful as blackmail if they’re not deniable. If there’s deniability, the would be blackmail victim can just say that the emails are fake and it’s he said/she said. It lowers the incentives for stealing emails.
  - crankyoldcrank 6y ago
    Don't worry, those emails are pretty much already down the memory hole.
- lucb1e 6y ago
  +1. What even is the use-case for plausible deniability? The way I heard it, is if your conversational partner is from the FBI and you want to whistleblow something, the plausible deniability can be used to plausibly deny that you said something to the agent. But who's the judge going to believe: the agent that claimed message X was sent to them, or the user who said that the agent must have forged message X? Heck, if the government is that suspicious of someone they can also order the ISP to setup a tap and see that the right number of bytes at the right time were sent. The feature requires extra complexity in security protocols, plus might give people a false sense that they can just deny anything afterwards when that is not the case. Checking Wikipedia to make sure I understand the point correctly, it claims it's more about denying that encryption was used at all (good luck with that one in an encrypted chat) or that there can be multiple plaintexts (so you can later come up with a completely different chat log, lying in court and claiming the other party has forged everything, which has the same issue as above). Transcript consistency on the other hand seems to me like an expected feature for any >2010 multi-party encryption protocol. That can be practically used to change the conversation shown to a third participant (taking a "yes" of mine from one place, pasting it elsewhere while withholding the original reply...).

ViViDboarder 6y ago

I’m not sure how exact to read this, but I’m curious how it differs from the Signal protocol.

baby 6y ago
Signal doesn’t really address group chat, or it does but in some very limited ways that won’t scale passed a lot of participants (depending which group chat protocol you use among the different ones that have been implemented with the Signal protocol). Now if you ask me why you would want end-to-end encryption in a group with hundreds, thousands, or more users I have no answer for you. IMO group chat passed 30 users should revert to public group chats instead of giving you a false sense of privacy.
- some_furry 6y ago
  > IMO group chat passed 30 users should revert to public group chats instead of giving you a false sense of privacy. Whether or not that's a "false" sense of privacy depends on your threat model. Is your primary threat "What if someone hacks the communication server and leaks our conversations?" (This is something I worry about a lot.) Is your primary threat "What if someone in our chat is a spy and we're planning crimes?" (This is something I don't worry about, but others might.) In the first case, E2EE for up to 1000 participants in a group still makes sense. In the second case, every additional participant is additional liability of government subversion.

motohagiography 6y ago

Oddly, I do work reasoning about security protocols and the notations in this still seem opaque. The trail of bits article has some standard notation in it in their cartoons, but both seem to jump between levels of abstraction. Does anyone pay to have these things described clearly?