Re: [MLS] Authentication

Thanks for the detailed write-up, Richard!

Here are my two cents:

1. SIGMA or Katz-Yung? 

No opinion yet, other than SIGMA might offer more options as you mentioned.

2. Pubkeys in roster? 

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? 
4. Roster in-band or out? 

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)

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)

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

In other words: before we can clearly answer questions 3 & 4, we need to answer the other questions I mentioned as well.

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:
> 
> Hey all,
> 
> 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.
> 
> Leaving the crypto details and protocol details for the PDF, the questions for the WG are as follows:
> 
> 1. Is there any reason to prefer one of the two constructions in the document over the other?
> 
> 2. The protocol enables agreement on a "roster" of participants.  Should that roster include only identities of participants, or also their public keys?
> 
> 3. Can we rely on clients keeping around a copy of the roster, so that they can then use it to authenticate future messages?
> 
> 4. Should the roster be distributed by the MLS protocol, or should MLS just provide a pointer?
> 
> 5. Other than the roster, what information should we enforce group agreement on?
> 
> The doc has some thoughts on the arguments on either side of all of these questions.  
> 
> 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.
> 
> Thanks,
> --Richard
> <group-authn.pdf>_______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls