Date: Wed, 25 Jul 2018 12:58:30 +0100
From: Dennis Jackson <dennis.jackson@cs.ox.ac.uk>
To: mls@ietf.org
Message-ID: <20180725125830.6af30662@T-200>
In-Reply-To: <2046EE4E-2F25-4E89-8844-0EDAAABA2A38@fb.com>
References: <1532516469.3570686.1452294728.424CDA78@webmail.messagingengine.com>
 <2046EE4E-2F25-4E89-8844-0EDAAABA2A38@fb.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
 boundary="Sig_/qhc.5z+FI2HxYb3Cek_uemT"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/ReOWc4Ycb-nP5QK1e03rHb7PnQY>
Subject: Re: [MLS] *re*joining a group with the same identity key
Precedence: list

--Sig_/qhc.5z+FI2HxYb3Cek_uemT
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.=20

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 <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=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.
>=20
> I don=E2=80=99t 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.
>=20
> Jon
>=20
> 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:
>=20
> Hi all,
>=20
> 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?
>=20
> 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.)
>=20
> 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.
>=20
> best,
> k
>=20



--=20
PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC

--Sig_/qhc.5z+FI2HxYb3Cek_uemT
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJbWGXnAAoJEGEFp3WM0kas548P/iHNndlus1HqNDTViu68yu/X
nN5qZD9F+Czb292y4CarJ9apBZflrmX+4XhhXi8KCdkk+aJOLnCaSBdu1GJrbCIa
10/kY0DHoGZNU6keea12XfyKfMMLZdZaoU1tuOIUUQolnj2JrRXPDJe3npiuhXaC
NVtdRR3JF1kuuNKuLRKFZd6uyWZ/81NMqQHxRn6llukp20AxrGWBvsgrLLWvD0PK
/nZBJcCVO9Ujphm47z7aqLow67FHzxTJJ4ChgrcxuXycskpfXqnudzuv4TREt1mo
fj8BYNDWRvydqN193l7HfvPuBAeGum6eXAiHGb5E7kBUVxdjcCOOKQuMpSHVzoe5
TP4lcgxDZN7rtkWRMDULl7PO4hAQuEyh7uWv6IpD6ei7bfJcyUd8ryKlTa/jhnv2
JK4NugmEYd0RMNWL0BQNxCIjgAqOFMT+wu9SDk7By3EIBQorq1BViY+wxkpggCHo
Kvqy7bONeFKtz7sO0TgOxPPjAPBdLhGhmq2cqNGP5fSjUajK/Vd6HBYcKV/7uC/g
7Sncc2LNV15FYBlT/gmeLdbDjIYprfIBRmh8vmYH5+FNiCNUeNiq8wSHf7kR1qj/
XxTMoGs+nxq7yBiedZvuTC7QyrlTkDMO8x3xpiUTaqN4OWYDMR/GPtgm4JaKz7fu
L3aAKAF0jZSMlMGDpu1u
=ddsp
-----END PGP SIGNATURE-----

--Sig_/qhc.5z+FI2HxYb3Cek_uemT--