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

I actually expect this to be a not-uncommon case.  Two use cases
immediately come to mind:

1. New devices in an application where identity keys are sync'ed among
devices
2. Participants who have lost state and need to re-sync.

On account of (1), I had been thinking that the mapping between members /
leaves in the tree and identity keys would not be one-to-one, but
many-to-one.  Are folks thinking that there would be technical problems /
ambiguities in such a case?  None are coming to my mind.

It does seem worth thinking about the re-sync case (2), i.e., the case
where a participant has most of his state.  If he's forgotten everything
besides his identity private key (or including the identity private key), I
don't think there's much you can do but treat him like a new participant.
If he remembers his position in the tree, it seems like you could do a
"re-sync" transaction that's like an add, but for that position in the tree
-- it's the same logic as an add, except instead of the frontier, you send
the copath for that position; for other nodes, it just looks like an Update
at that position.

(Aside: This reinforces that we really only have 1.2 operations here:
Update + handle-update-at-edge + encrypt-leaf-secret)

It also seems like if we can solve the "re-sync a member with lost state"
problem, then we can probably also solve the "heal a network partition"
problem that Dennis raises.  Assuming we can choose a winning partition and
appoint someone to do the merge, the person doing the merge can just
re-initialize the losing members to their point in the tree, as if they had
lost their state.

--Richard

On Wed, Jul 25, 2018 at 7:59 AM Dennis Jackson <dennis.jackson@cs.ox.ac.uk>
wrote:

> me@katriel.co.uk<mailto:me@katriel.co.uk> 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 <jmillican@fb.com> 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"
> > <mls-bounces@ietf.org<mailto:mls-bounces@ietf.org> on behalf of
> > me@katriel.co.uk<mailto:me@katriel.co.uk>> 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
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>