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

On Thu, Jul 26, 2018 at 8:42 AM, Richard Barnes <rlb@ipv.sx> wrote:

> 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.
>
>
I think there is an ambiguity, but it is fairly easy to resolve.  There are
cases where a participant attempting to add themselves with the same
identity to an existing group is implicitly replacing their previous
connection.  Katriel called that out as:  "Perhaps the simplest is to allow
the device to double-join but require it to immediately delete the old copy
of itself."  There are others where this is a true add-a new device that
should also receive communication.  I think the fix here is to replace
"require it to immediately delete" with "allow it to immediately delete";
that seems to support both use cases and make the decision about which is
in use explicit and in the user's control.

Ted

> 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
>>
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>
>