From: Raphael Robert <raphael@wire.com>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 7 Sep 2018 22:45:33 +0200
References: <CAL02cgQeVdvpUrjbaQn67MoYMb1tzBZCPPsz3cvDpQxZ_kJijQ@mail.gmail.com>
To: mls@ietf.org
In-Reply-To: <CAL02cgQeVdvpUrjbaQn67MoYMb1tzBZCPPsz3cvDpQxZ_kJijQ@mail.gmail.com>
Message-Id: <1E76A31F-5F2D-496C-BAC3-4C8CF8D2ECDC@wire.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/v4ZqKnmJmHSnkQUFgV2RG3cCvwg>
Subject: Re: [MLS] Authentication
Precedence: list

Thanks for the detailed write-up, Richard!

Here are my two cents:

1. SIGMA or Katz-Yung?=20

No opinion yet, other than SIGMA might offer more options as you =
mentioned.

2. Pubkeys in roster?=20

I think this begs the question what a public key stands for. Its scope =
could be a) per participant, b) per device of participants, c) per =
conversation, d) a combination of c + d. Additionally, it could be =
short-lived as you mention, meaning it could be rotated within a =
conversation.
I think we should start with public keys (regardless what they stand =
for) that might be short-lived, but assume the rotation happens =
out-of-band.

3. Clients store roster?=20
4. Roster in-band or out?=20

These two questions are somewhat linked. I think we want to achieve =
several goals here:

 - protocol simplicity (points to in-band roster stored on clients)
 - protocol efficiency (points to having the roster stored on a server, =
so that clients don't have to upload several MBs just to invite someone =
to a large group conversation)
 - anonymity (again points to the in-band solution)
=20
The last point probably deserves more explanation: With client-side =
conflict resolution not being a likely option for MLS, the assumption is =
that a server will assist with message ordering and other tasks. This =
makes it a somewhat centralised system, even if it doesn't preclude =
federation as such.
If the server is tasked to fan-out a message encrypted under a key =
established by MLS, observable metadata on that server will include =
either the identity or an alias of the recipients of that message. As =
such, anonymity is not something that can be achieved on the observable =
metadata level.
However, there might still be the option of not storing the group member =
list in clear text on the assisting server. This would address scenarios =
where such group membership lists could be a risk: one-off server =
breaches (without any persistent compromise), improper deletion =
mechanisms, etc.

A possible solution could be the following:
 - servers can store anonymised ratcheting trees (meaning the identity =
of members is not part of it), this helps when adding or removing =
participants
 - the roster is either in-band or encrypted on a server
 - we assume there is a viable solution to guarantee integrity =
(additional Merkle trees were mentioned)
=20
There is a follow-up question to this: If the server doesn't know the =
roster, how can it be tasked to do a proper fan-out of a message to the =
group?

Possible solutions are:
 - The client sending the message also send the list of recipients =
(roster) to the server along with the message
 - The roster is stored encrypted on the server and the server receives =
the decryption key along with the message, uses it for the sole purpose =
of fanning-out the message and forgets it immediately afterwards
=20
In other words: before we can clearly answer questions 3 & 4, we need to =
answer the other questions I mentioned as well.
=20
5. What to KDF?

Adding as much as possible into the KDF sounds like it makes things more =
robust, but doesn't this imply total message ordering? (Something that =
might or might not be necessary with TreeKEM)

> On 7 Sep 2018, at 00:00, Richard Barnes <rlb@ipv.sx> wrote:
>=20
> Hey all,
>=20
> I've been stewing about authentication for a little while, and I think =
I've gotten to a point where I have coherent-enough thoughts to share =
with the group.  (Though by no means final)  The attached PDF has some =
slightly stream-of-consciousness thoughts about authentication for MLS, =
but it ends up with (1) some crypto protocols with a degree of =
validation and (2) a loose proposal and some questions for the WG.
>=20
> Leaving the crypto details and protocol details for the PDF, the =
questions for the WG are as follows:
>=20
> 1. Is there any reason to prefer one of the two constructions in the =
document over the other?
>=20
> 2. The protocol enables agreement on a "roster" of participants.  =
Should that roster include only identities of participants, or also =
their public keys?
>=20
> 3. Can we rely on clients keeping around a copy of the roster, so that =
they can then use it to authenticate future messages?
>=20
> 4. Should the roster be distributed by the MLS protocol, or should MLS =
just provide a pointer?
>=20
> 5. Other than the roster, what information should we enforce group =
agreement on?
>=20
> The doc has some thoughts on the arguments on either side of all of =
these questions. =20
>=20
> The next step here is to generate a pull request that makes a concrete =
proposal.  If folks have thoughts about the overall plausibility of the =
analysis here, or thoughts on the design trade-offs highlighted above, =
that would be helpful as I work on fleshing this out.  Hope to have a PR =
in flight in time for the interim.
>=20
> Thanks,
> --Richard
> <group-authn.pdf>_______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls