Return-Path: X-Original-To: mls@ietfa.amsl.com Delivered-To: mls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F52131157 for ; Thu, 26 Jul 2018 08:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoX2G6qoouPq for ; Thu, 26 Jul 2018 08:42:24 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 716CA130EA5 for ; Thu, 26 Jul 2018 08:42:24 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id q11-v6so3723233oic.12 for ; Thu, 26 Jul 2018 08:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HM+2zfboEOKLN/knBJvKZraJBlAIb0A9qOq0+CyNmDg=; b=dUhUbYgPifuMaKZF+tWw4jkxZ3zn8OUXisCn3gF34N++2+kOMkAO4kTyJOQzSN0P/t hsFvaZzGObky250w5rGrGcqbrrjjc5alvOL7ja84/RHKHIT84A6Sx+/WQhATktTLn3Hq +EG6WLoFqHVSksD/60eETY7jB5fJ4CW0tN+5xu+PJZzIxafDc34eu0MwSCMOehPywLbu lUATrTD+SrFVlvXOyVOpYvbN8UVJfmED062Hvo9wkx1cjXznfDTlz5kBtSc8oSl1tg+e lPoUavwOnLwdX2T3/GIrzX4ODCs/sitXaFoxo3kGO3PmiJxPOxuFlZvE1k7/6bxn4dEP wqxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HM+2zfboEOKLN/knBJvKZraJBlAIb0A9qOq0+CyNmDg=; b=rjkTk+eO2fTw7KgnYfs0VRpLve3GOhx95cDmdsGZ2Pt0f7FbyUj9cLjeaC7xP2S8Nm QbCdWy3SwDd3KjQfq8VjbJrG8VFtELj9VvHH223Dzn2EVjJa8Ryciqg993CgvfMqO+QQ 0mAiA9aY5zgotqlq4cvcKxYuOT9ZU604q5F8KyMkBL/x/tQtN3mTEbym1gJIqCtOjTOw 2UQ2D85ZHY7jLpWbiiyhRwOT3LojjSr9dPKLNDiXNu3ai6IeJWvIPEG75V/1g0WLZb8U TuTx+ROemawfgNBaYnEu0BCne3NhVgT1qNnByLvD439bhVcrEuAPL6AzslBPfZ1qiaf0 6pVQ== X-Gm-Message-State: AOUpUlEV8YsXMqbEwWDN07mK+Xlpsu4M4P7HY6/EnS0r1EVIkXD/Uj5i U+pX8GcMRgV31rHHmpZzp4SjpgCbPxEjyCc567AvBA75G8E= X-Google-Smtp-Source: AAOMgpd+r2dM0G3bhNpbDg4LUuScudaWfeS5KSd6spzeAdmLvGe0gtNyIXrd995x1gmrHLGnOm57ZiFG5zALrY1OcJA= X-Received: by 2002:aca:ce51:: with SMTP id e78-v6mr2362637oig.225.1532619743631; Thu, 26 Jul 2018 08:42:23 -0700 (PDT) MIME-Version: 1.0 References: <1532516469.3570686.1452294728.424CDA78@webmail.messagingengine.com> <2046EE4E-2F25-4E89-8844-0EDAAABA2A38@fb.com> <20180725125830.6af30662@T-200> In-Reply-To: <20180725125830.6af30662@T-200> From: Richard Barnes Date: Thu, 26 Jul 2018 11:42:11 -0400 Message-ID: To: dennis.jackson@cs.ox.ac.uk Cc: mls@ietf.org Content-Type: multipart/alternative; boundary="0000000000006535ea0571e8d7e6" Archived-At: Subject: Re: [MLS] *re*joining a group with the same identity key X-BeenThere: mls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Messaging Layer Security List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 15:42:27 -0000 --0000000000006535ea0571e8d7e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > 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=E2=80=99t know any group state. It=E2=80=99s an appl= ication-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 =E2=80=9Crecove= ry=E2=80=9D > key after every update). > > Best, > Dennis > > On Wed, 25 Jul 2018 11:05:09 +0000 > Jon Millican 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=E2=80=99s > > 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=E2=80=99t have strong feelings about this vs your proposed soluti= on > > 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" > > on behalf of > > 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 > --0000000000006535ea0571e8d7e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I actually expect this to be a not-uncommon case.=C2= =A0 Two use cases immediately come to mind:

1. New= devices in an application where identity keys are sync'ed among device= s
2. Participants who have lost state and need to re-sync.
<= div>
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.=C2=A0 Are folks thinking that there would be technica= l problems / ambiguities in such a case?=C2=A0 None are coming to my mind.<= /div>

It does seem worth thinking about the re-sync case= (2), i.e., the case where a participant has most of his state.=C2=A0 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 bu= t treat him like a new participant.=C2=A0 If he remembers his position in t= he tree, it seems like you could do a "re-sync" transaction that&= #39;s like an add, but for that position in the tree -- it's the same l= ogic as an add, except instead of the frontier, you send the copath for tha= t 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=C2=A0+ handle-update-at-edge + encrypt-leaf-sec= ret)

It also seems like if we can solve the &q= uot;re-sync a member with lost state" problem, then we can probably al= so solve the "heal a network partition" problem that Dennis raise= s.=C2=A0 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.
<= div>
--Richard


On Wed, Jul 25, 2018 at 7:59 AM Dennis Ja= ckson <dennis.jackson@cs.o= x.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<= br> > 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=E2=80=99t know any group state. It=E2=80=99s an applic= ation-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 =E2=80=9Crecovery= =E2=80=9D
key after every update).

Best,
Dennis

On Wed, 25 Jul 2018 11:05:09 +0000
Jon Millican <jmil= lican@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=E2=80=99s > frontier. We could then reject somebody double-joining their own
> identity key; under the assumption that this could only happen with a<= br> > malicious server anyway.
>
> I don=E2=80=99t have strong feelings about this vs your proposed solut= ion
> 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-boun= ces@ietf.org<mailto:mls-bounces@ietf.org> on behalf of
> me@katriel.co.uk= <mailto:me@kat= riel.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<= br> > 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
--0000000000006535ea0571e8d7e6--