Re: [MLS] *re*joining a group with the same identity key

[Dennis Jackson <[e-mail]>]

[e-mail]<mailto:[e-mail]> wrote:

> The simple answer is to forbid such joins, but this might happen if a
> device forgets its group state but remembers its identity key.

Depending on how MLS specifies update operations, this could also
happen if there was a network partition and some group members see a
different order of key updates. Even if we assume the existence of a
delivery service which can provide a linear order for key update
messages, the attacker will be allowed to compromise the server and
violate this property. Consequently, some participants will have
differing views of the group key and need to converge.

In both cases we have a long term key, already in the group, with bad
local state. I think we need a recovery mechanism for this other than
just starting a new group or allowing a rejoin since that would allow
an attacker with only knowledge of a long term key to join a previously
secure group. 

We could mitigate this by proving knowledge of some recent state: a
device which knew the group key five minutes ago is more trustworthy
than one which doesn’t know any group state. It’s an application-layer
decision to actually figure out what to do in this case, but we could
expose a way to prove state knowledge (e.g. by deriving a “recovery”
key after every update).

Best,
Dennis

On Wed, 25 Jul 2018 11:05:09 +0000
Jon Millican <[e-mail]> wrote:

> One potential option that comes to mind is for the server to help it
> reinsert itself in the correct place. This would essentially amount
> to a join, but serving its own copath instead of the group’s
> frontier. We could then reject somebody double-joining their own
> identity key; under the assumption that this could only happen with a
> malicious server anyway.
> 
> I don’t have strong feelings about this vs your proposed solution
> though. The main benefit would probably be just in terms of keeping
> the tree cleaner and minimising remove operations that need to be
> done.
> 
> Jon
> 
> On 25/07/2018, 12:01, "MLS on behalf of Katriel Cohn-Gordon"
> <[e-mail]<mailto:[e-mail]> on behalf of
> [e-mail]<mailto:[e-mail]>> wrote:
> 
> Hi all,
> 
> Here'a s case we might want to think about: what should happen if a
> current member of a group asks to join, with the same long-term key
> that they're already joined with?
> 
> The simple answer is to forbid such joins, but this might happen if a
> device forgets its group state but remembers its identity key.
> (Perhaps it writes the group state to a local database and the write
> got corrupted.)
> 
> Alternatively I see a handful of different ways we could support
> these joins, if we wanted to. Perhaps the simplest is to allow the
> device to double-join but require it to immediately delete the old
> copy of itself.
> 
> best,
> k
> 



-- 
PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC