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

["Katriel Cohn-Gordon" <[e-mail]>]

One thing to be clear about: all of these "rejoin"-style operations
break post-compromise security in some way, because they allow an actor
who knows long-term keys but not the current state to become a full-
fledged group member.
That's not to say we shouldn't support them, of course (it's no good
building a secure protocol that doesn't work), just that we should be
careful about when they can happen. I think it's also important to make
sure they're clearly differentiated from normal operations, so that
applications can disallow them or show warnings.
k

On Thu, 26 Jul 2018, at 5:43 PM, Ted Hardie wrote:
> On Thu, Jul 26, 2018 at 8:42 AM, Richard Barnes <[e-mail]> 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
>> <[e-mail]> wrote:>>> [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>>> _______________________________________________
>>>  MLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mls
>> 
>> _______________________________________________
>>  MLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mls
>> 
> _________________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls