Re: [MLS] External Commits

You raise good points. I will throw in some thoughts on a few of these:

1) This has definitely been the case for pair-wise connections – if Alice desyncs such that her conversation with Bob is unrecoverable, they just start an entirely new session wherein trust is based only on identity keys. That then relies on OOB authentication of those keys / trust-on-first-use/etc. The group context is a little different due A) the entire group does not tear-down when Alice desyncs to rebuild a new session and B) it is much easier to be a passive observer such that it is harder to notice if attacker-as-Alice is not behaving as Alice.

Some of these irregularities in group messaging link to the reason that the working group so often requires knowledge of the current group state for Alice to make use of keys/send updates/etc. vs. just knowledge of her signature key. By requiring knowledge of the group state, we get continuity for the entities involved from the point of trust-on-first-use of the signature keys. However, if we allow Alice to enter/reset at any time without that continuity in proving knowledge of the group state, then we actually allow subversion against many of the mechanisms that we have put in place elsewhere in the protocol.

The distinction here is between joining a session as a new member (where the app decides how entity authentication is handled and users decide who gets to join) and re-joining a session as an already trusted member with all the in-app privileges that were held by the real Alice.

2) I agree that the resumption secrets infrastructure that we have already could work very well here.

3) The threat model is actually a rather critical aspect of this, as there is a subtle entanglement with the PCS claims. Traditional PCS states that after an epoch wherein the attacker is passive, the security is “healed” with the attacker locked out – even if the attacker becomes active later. Now that is no longer the case and we must assume that the attacker continues to be passive indefinitely (or until signature keys are rotated) for PCS to hold. For example, suppose that Alice’s full state is compromised. One epoch later the group state is no longer of use to the attacker. However, the attacker still has the signature keys and can perform the external commit – remove Alice – impersonate Alice sequence. There are cases where signature keys may be compromised without the rest of the state, but I will focus on the above example for now.

Note that even the “solution” I proposed before does not prevent this break in PCS assumptions/guarantees. It would, however, imply an i-epoch PCS variant. For example, the attacker gets the signature and resumption secrets and is passive for i=2 epochs, and we only allow re-syncs within those i=2 epochs before considering Alice to be an entirely new zero-trust member. Alice can resync within i=2 epochs while providing group members some assurance that she is still the same entity, and there is an i-limit on the number epochs we require the attacker to be passive, thus still allowing for a form of PCS.

4) I do not have a solid proposal for this. One possibility could indeed be that if a signature key already exists in the tree we assume that Alice is attempting a resync (i.e. if Alice is not in the tree at all then she is a new member or else should prove knowledge of a past state). Another could be a list of current group members/identity keys.

Britta

From: Raphael Robert <raphael@wire.com>
Date: Monday, November 23, 2020 at 5:59 AM
To: "Hale, Britta (CIV)" <britta.hale@nps.edu>
Cc: "mls@ietf.org" <mls@ietf.org>
Subject: Re: [MLS] External Commits - Resync

Hi Britta,

That’s definitely an interesting question. The way the spec is written right now, Alice could just re-sync like you described and that raises a few questions (in no particular order):

 - The status quo with messaging apps is that you can typically join a session by only controlling the identity key. This is the case for messengers based on the Signal protocol.  While a session gives you certain well-understood guarantees, it’s up to the apps to define how seamlessly you can initiate a new session (https://github.com/signalapp/Signal-iOS/issues/4138). While that’s the status quo, it doesn’t mean we shouldn’t aim higher with MLS.

 - You mention the proof of past participation and I think the resumption secrets we already have could be used for that (https://messaginglayersecurity.rocks/mls-protocol/draft-ietf-mls-protocol.html#name-resumption-secret). Provided other members keep them around for long enough, Alice could prove that was indeed a member in the past.

 - What is the exact threat model? An attacker that compromises a device will not only get the signature key, but most likely also the resumption secrets. The intuition here is that it is unlikely that the resumption secrets are better protected on the device than the signature key itself (but I might be wrong). We also recommend that signature keys should not be re-used between devices, which lowers the chance that they leak when they are copied (they probably don’t have to be copied ever if they are not re-used). Given the above, I’m wondering if you had a particular scenario in mind?

 -  Let’s say we wanted to address this. The practical problem I see is that it might be impossible for other members to determine if Alice is trying to re-sync. There was some discussion on this now closed PR: https://github.com/mlswg/mls-protocol/pull/439. If we don’t have a way to uniquely distinguish between members (other than by their position in the tree), how can we detect that they are trying to re-sync?

I’m all for continuing the discussion though! Maybe we won’t find a satisfying solution, but we should try at least.

Thanks

Raphael

On 21. Nov 2020, at 00:17, Hale, Britta (CIV) <britta.hale@nps.edu<mailto:britta.hale@nps.edu>> wrote:

Hi all,

A good point was raised by Jonathon Hoyland during the MLS IETF 109 meeting regarding possible concerns in using external commits for resync, particularly in the case of Alice adding/removing herself. Richard noted that this is a feature in the case that Alice is no longer synchronized with the group and therefore can use an external commit to add herself back in, removing the previous version.

As opposed to any newcomer joining with an external commit, the case of Alice re-joining presents a potential security issue. Namely, as currently specified (in my reading of the draft), an existing group member, Bob, has no means to distinguish between the following cases:

  1.  Alice needs to resync and therefore performs an external commit and removes her prior version.
  2.  Alice’s signature keys are compromised (it is not necessary for the adversary to compromise any group state). The adversary performs an external commit in Alice’s name, and then removes her prior version and impersonates her to the group.

One might hope that Alice notices that she is removed and communicates this to the group members OOB, but it is also possible that that she assumes some other reason for the removal, is offline, or simply is not active enough to take action for a fairly long compromise window. Even if she tries to use an external commit to get back into the group and then removes the adversary-as-Alice, there is no means for other group members distinguish the real Alice from the adversary-as-Alice and the process could be circular (until new valid identity keys are issued).

While a newcomer is a fresh source to be trusted or not, Alice has been “healing” along with the group and the above option (2) allows the adversary to bypass all of that.

The source of the problem is that when Alice re-syncs, she is not providing any validation of being the same/previous identity, so it is easy for other group members to accept that nothing more than a resync has taken place. Thus, a fairly straightforward solution is to require PSK use in cases where an external commit is used for resync. By enabling a PSK derived from a previous epoch during which Alice was part of the group to be injected with the external commit, Alice provides some proof of prior group membership and we avoid the total reset.

What does everyone think about this? Is it a problem that we want to address, or let it fall out-of-scope?
(Also, if I missed something in the draft that already fixes this, please point it out.)

- Britta

_______________________________________________
MLS mailing list
MLS@ietf.org<mailto:MLS@ietf.org>
https://www.ietf.org/mailman/listinfo/mls