Subject: [hrpc] Thoughts on MLS Internet Draft?

From: Shivan <[email-masked]>
Date: Mon, 5 Feb 2018 12:00:10 -0500

Hi all,

Wondering if anyone had any thoughts on the early draft of MLS (Messaging
Layer Security) protocol:

https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/

It'll be used to enable e2e encrypted group chat with forward secrecy,
which is a an important and interesting problem with ramifications for
human rights groups.

Thanks,
Shivan

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 12 Feb 2018 21:32:03 +0100

On Mon, Feb 05, 2018 at 12:00:10PM -0500,
 Shivan <[email-masked]> wrote 

> https://datatracker.ietf.org/doc/draft-barnes-mls-protocol/

The goal is important (secure *group* communications), I cannot really
say something intelligent about the protocol, but it is certainly
something to encourage.

The security considerations mentions only *technical* security
issues. But group communications have a big non-technical issue when
it comes to confidentiality: *one* rogue or careless member of the
group is enough to compromise all the group conversations. The draft
mentions that the protocol scales to "thousands of participants". But
it is unrealistic to hope you can keep something secret when it is
shared by thousands of people.

---

From: Shivan <[email-masked]>
Date: Mon, 12 Feb 2018 17:06:37 -0500

> shared by thousands of people.

​That ​problem is intractable though - if someone can see a message, they
can take a photo of it.

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 13 Feb 2018 13:04:09 +0100

> shared by thousands of people.

Good point. Maybe information could be added on (intentional)
degradation and/or retention?

Best,

Niels

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 13 Feb 2018 14:52:33 +0100

On Mon, Feb 12, 2018 at 05:06:37PM -0500,
 Shivan <[email-masked]> wrote 
 a message of 46 lines which said:

> ​That ​problem is intractable though - if someone can see a message,
> they can take a photo of it.

The problem is old (I remember seeing it mentioned in the first PGP
documentations) and well-known but it is much worse for a large
group. Two people can keep a secret, not hundreds of people.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Feb 2018 10:52:18 +1100

> shared by thousands of people.

From a HR standpoint, I find this draft fascinating.

HTTPS is explicitly a two-party protocol, and there have been a number of attempts to interpose additional parties into it. Offhand, I'd say most Internet protocols that are secure follow that pattern.

OTOH this protocol is multi-party by design -- which is fine if all of the parties are peers (which seems to be assumed). If one or more parties' participation is coercive -- e.g., an employer, a government, etc. -- things can go pear-shaped pretty quickly, from a HR perspective.

I'm not sure what the protocol itself can do to avoid that, beyond the obvious things it'd be doing anyway (not allowing a party to interpose itself without some explicit permission, etc.). There might be client UI / configuration things that make abuse here easier or harder - should that go into the protocol draft?

I can also see echos of this in the forthcoming discussion of draft-yasskin-http-origin-signed-responses; HTTPS URLs have a semantic of being communication between two identified parties, with certain properties (authentication, integrity, confidentiality); is it reasonable to use them for something that loses confidentiality by involving a third party?

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Harry Halpin <[email-masked]>
Date: Wed, 14 Feb 2018 20:07:26 +0100 (CET)

----- Mail original -----
> De: "Mark Nottingham" <[email-masked]>
> À: "Stephane Bortzmeyer" <[email-masked]>
> Cc: "Shivan" <[email-masked]>, "Hrpc" <[email-masked]>
> Envoyé: Mercredi 14 Février 2018 00:52:18
> Objet: Re: [hrpc] Thoughts on MLS Internet Draft?
> 

Note that it is a huge improvement over one giant shared secret key, which is the previous method used by Signal - 
or even the lack of encryption on group chats at all by Telegram (despite many users believing they are secure). So
I can't imagine any reason why we would not support this protocol in terms of user security/privacy, as the
perfect should not be the enemy of the good. 

While adding people to a group naturally increases the chances of security breaches, it is a valid use-case, as there
are many places (Russia and Iran come to mind) where the freedom to assembly is organized via *very* large Telegram
(multi-thousand user) groups, which is the kind of app this protocol is aiming at. We discovered this via doing 
 a study on secure messaging with human rights activists, and were a bit surprised by this as well!
https://nextleap.eu/res/Ermoshina_EuroUSEC_final.pdf

A sequel with stats is coming out with much more users, as we recorded those numbers but needed time. However, the main
interesting result is that for many human rights activists, the chances of their local client being seized is considered
*much* higher than pervasive surveillance. So in some ways, perhaps the entire peer-to-peer with storing key on the device
is more a "Western privacy activist" model than one actually needed by people at risk. 

> HTTPS is explicitly a two-party protocol, and there have been a number of
> attempts to interpose additional parties into it. Offhand, I'd say most
> Internet protocols that are secure follow that pattern.
> 
> OTOH this protocol is multi-party by design -- which is fine if all of the
> parties are peers (which seems to be assumed). If one or more parties'
> participation is coercive -- e.g., an employer, a government, etc. -- things
> can go pear-shaped pretty quickly, from a HR perspective.

The obvious other design choice is a shared key ran by a central server after
it runs two-party key establishment with every member of the group.

The goal of MLS is an IETF standard for Signal-like peer-to-peer
encrypted communication, so the goal is avoid coercion on the server-end (such
as can be done in HTTPS) and thus the likely view a shared key ran by a single
server as a more dangerous threat than a peer being compromised. Again, that
might be the wrong threat model, but that's what people's goals are right now. 

> 
> I'm not sure what the protocol itself can do to avoid that, beyond the
> obvious things it'd be doing anyway (not allowing a party to interpose
> itself without some explicit permission, etc.). There might be client UI /
> configuration things that make abuse here easier or harder - should that go
> into the protocol draft?
> 
> I can also see echos of this in the forthcoming discussion of
> draft-yasskin-http-origin-signed-responses; HTTPS URLs have a semantic of
> being communication between two identified parties, with certain properties
> (authentication, integrity, confidentiality); is it reasonable to use them
> for something that loses confidentiality by involving a third party?

Great questions, and I agree the protocol needs work but I find the design to be really going in the right direction
and overall, fairly solid (although it's mostly Oxford, in full disclosure my co-workers at Inria are helping). 

There is a call for a BOF in London, so having people from this group there would be great. 

> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Feb 2018 08:59:01 +1100

> On 15 Feb 2018, at 6:07 am, Harry Halpin <[email-masked]> wrote:
> 

Oh, absolutely. I was more thinking about how one of the oft-heard arguments against standardising MiTM is that "it's hard to secure more than two-party communication," and how this might be used as evidence otherwise.

What's been more convincing in those discussions has been the argument that RFC7230 standardises HTTPS as two-party communication, and broadening it to multi-party can't be done without violating the assumptions of users and other parties; i.e., the standard is effectively a contract, and you can't break it.

Here, we're seeing the opposite; security is being improved for communication that's already explicitly multi-party.

Ratchets are awesome :)

Cheers,

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Feb 2018 22:21:16 +0000

On 14/02/18 21:59, Mark Nottingham wrote:
> Oh, absolutely. I was more thinking about how one of the oft-heard
> arguments against standardising MiTM is that "it's hard to secure
> more than two-party communication," and how this might be used as
> evidence otherwise.
> 
> What's been more convincing in those discussions has been the
> argument that RFC7230 standardises HTTPS as two-party communication,
> and broadening it to multi-party can't be done without violating the
> assumptions of users and other parties; i.e., the standard is
> effectively a contract, and you can't break it.

I agree that the former argument isn't by itself strong (mail
transport security works pretty well after all) and that the
latter is better. However, the former argument is fine if the
context of the discussion relates to an existing two party
protocol, which has been the case with many of discussions
related to breaking TLS.

On the MLS thing - it seems like a good thing to me, if it
works out as planned. (Even better if we could get interop
between different services using the results, but that's sadly
too ambitious I guess.)

Cheers,
S.

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)