[MLS] User study relevant to MLS

[Harry Halpin <[e-mail]>]

I'd just like to bring to everyone's attention a relatively large-scale user study done at Inria on secure messaging, with a focus on developers and high-risk users of secure messaging apps with groups (and thus a bit different than most user studies, that focus on university students and on pairwise messaging). 

Of course, I'd just like to summarize some points - and note overall, MLS is doing the right thing: 

1) Scalable group messaging is a real use-case: Many groups of high-risk users end up using Telegram rather than Signal and even WhatsApp due to its support for large groups, with groups of 600 not being unusual - and these groups have a lot of "chat" are are not just broadcast groups. Also, in some countries where the Web is censored, there are news groups with large (50,000) users. So, the idea to aim for scalability by MLS is the right one. 

2) Authentication of users in a group ends up being more important than deniability. While deniability is cryptographically very interesting, in practical use-cases we do not have any evidence to support key material ever being used in a court case to convict someone (for example, the Manning vs. Lamo case where Manning used OTR), as social context is used by the courts. That being said, it would be useful to support as an optional feature, because one never knows how sophisticated enemies may become in the future. The obvious idea that Benjamin, Sophia, and others have discussed is to enable out-of-band optional use of deniable keys (i.e. ring signatures if needed or key establishment via deniable channels). However, scalable group messaging is more important than deniability. 

3) Support for Pseudonymity: People really want pseudonyms per group in high-risk contexts, which is important. While this is more of an Authentication Service concern, it seems that if possible reducing or make optional the use of long-term identity keys for signing messages in MLS and instead having per-group long-term signatures vie a KDF of the identity key when joining a new group may be the way to go. That being said, users do indeed do some sort of verification (often out of band), so from an application-level per group (not per message authentication) should be possible, so some kind of long-term group key per participant is needed. 

4) Group Management: One of the greatest issues facing users of Signal is not being able to remove people from groups. This should be fixed by MLS, which is great news for everyone all around. The issue of archives, etc. is relatively controversial (and I assume dealt with by the Delivery Service) but should be possible. I think the current MLS approach of storing a hash of the archive and for having groups that need archiving, the DS can store and replay old messages seem right. 

5) Privacy: That being said, anything that reveals unnecessary details of participants in the group can be dangerous, particularly the "social graph" of who knows who. So, for example, if an admin creates a group, they may add new users who are their close friends first, and then others. As has been noted by Benjamin and Karthik in conversation, the tree of participants' key material in MLS may leak the ordering of participants, and there may be other, more subtle attacks. Thinking through these is worth it, such as randomizing the addition of new users to a group and so their place in the tree. 

Also, there's generally positive feelings about using standards and decentralization, although it's less important for people who are very high-risk users). I hope this report helps! For the full version (published as "Harry Halpin, Ksenia Ermoshina, Francesca Musiani:Co-ordinating Developers and High-Risk Users of Privacy-Enhanced Secure Messaging Protocols. SSR 2018: 56-75") see: https://hal.inria.fr/hal-01966560/document 

yours, 
harry