Re: [MLS] Short review of MLS drafts from the OTRv4 group

[Benjamin Beurdouche <[e-mail]>]

Hi Sofía,

Thanks a lot for the review, this is always very helpful !
(see inlined)

> On Feb 14, 2019, at 7:05 AM, Sofia <[e-mail]> wrote:
> 
> Hi, everyone!
> 
> Hope you are good!
> 
> First of all, thanks so much for all the efforts that this group has made! I
> attended the past interop meeting but it was hard to collaborate remotely ;)
> 
> We reviewed both drafts of MLS (https://github.com/mlswg/mls-architecture/blob/master/draft-ietf-mls-architecture.md
> and https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md)
> in little detail, as they seem to be an ongoing work.
> 
> The first thing that stood out is that some formatting and restructure might be
> needed. I really like these two issues: https://github.com/mlswg/mls-protocol/issues/110
> and https://github.com/mlswg/mls-protocol/issues/108, as they show that it will
> be nice (and maybe it will make easier for readers) to have a little bit of
> more structure. Some improvements on the markdown syntax might be good as well ;)

I think we completely agree one this. In general it is worth to note that I believe the WG
generally understands quite well the protocol compared to the description written
down in the two documents, but this is no excuse especially for people joining now
and for future readers of the document. All editors will ensure that the text makes
considerable progress in terms of readability and level of details. This quite difficult
to achieve in practice but we will spend a lot of time on it… :) 

> We also think that maybe more formal definitions of the security properties
> provided by MLS might be needed. Specifically, for 'forward secrecy', for
> example, the definition given on this paper might be in place:
> https://eprint.iacr.org/2000/014.pdf
> We are also unsure on the 'type' of forward secrecy provided. The Signal's X3DH
> protocol, for example, provides a forward secrecy between strong and weak. We
> are unsure if the way the Delivery Service, as defined in MLS, when providing the
> authentication keys and initial keying material, achieves which type of forward
> secrecy. But, of course, this can be a misunderstood from our side.

I believe that the mechanism used to fetch ephemeral init keys in MLS is very
similar to the one you would use to fetch a "pre-key" for Signal. The difference
is how the keys are mixed in the group secret which will provide specific guarantees.

I opened https://github.com/mlswg/mls-architecture/issues/48

> At some points, it might be nice to give recommendations in the spec:
> "It is left to the application to determine the interval of time between Update
> messages.". It is maybe good to provide an example of this time frame.

At IETF last summer we agreed that we need to provide example recommandations
regarding key-update frequency in the specification but I believe that we probably
will wait a bit longer to have real world measurements before we can do that as it
depends on the use-case (frequency of each group operation) and the number
of members in the group, hence is not super easy to simulate.

https://github.com/mlswg/mls-architecture/issues/49

> It is also unclear at some points the notation used for the Diffie-Hellman or
> Elliptic Curve parameters. Related to this, is unsure if this protocol takes
> into account the cofactor issues.

Thank you for reminding us, we will look into this.

https://github.com/mlswg/mls-protocol/issues/118

> We are unsure if there is a will of including deniability in this. On some
> points it states:
> 
> """
> [[ OPEN ISSUE: Signatures under the identity keys, while simple, have
>   the side-effect of preclude deniability.  We may wish to allow other
>   options, such as (ii) a key chained off of the identity key, or (iii)
>   some other key obtained through a different manner, such as a
>   pairwise channel that provides deniability for the message
>   contents.]]
> """
> 
> """
> Non-Repudiation and Deniability
> As described in {{client-compromise}}, MLS provides data origin authentication
> within a group, such that one group member cannot send a message that appears to
> be from another group member. Additionally, some services require that a
> recipient be able to prove to the messaging service that a message was sent by
> a given Client, in order to report abuse. MLS supports both of these use cases.
> In some deployments, these services are provided by mechanisms which allow the
> receiver to prove a message's origin to a third party (this if often called
> "non-repudiation"), but it should also be possible to operate MLS in a "deniable"
> mode where such proof is not possible. [[OPEN ISSUE: Exactly how to supply this
> is still a protocol question.]]
> """
> 
> If this is something that wants to be included, we will be very happy to answer
> questions. Nevertheless, there is no way, currently, to achieve the same deniability
> properties OTRv4 has in a group setting.

There was limited discussion in the working group and I believe deniability is not in the charter.
That said, I believe that our goal, at least mine, is to make sure that we can provide
deniability optionally on top of the current design, typically by sharing the signature
public keys over pairwise deniable channels at the cost of linearity. This is something
you might want to ask to the list or the chairs. In the mean time I added an issue.

https://github.com/mlswg/mls-architecture/issues/50

> We are also unsure of the difference between deniability and non-repudation.
> 
> This is very high-level review. We are very sorry if we misunderstood something.
> We will be very happy to further check issues, if wanted. We can also help on
> trying to give more structure, but I'm unsure where this is done: on the
> github instance?

Thanks a lot for the offer, I believe the best way to currently for the document is to
keep submit issues in the Github or PRs for limited changes so that we can make
these better. On the protocol side there are many things to look at such as federation,
user initiated add or eventually ephemeral signatures, and I am sure help will
be very appreciated as this review was... : )

Best,
Benjamin

> 
> Please, let us know where we can help.
> 
> Hope this is helpful!
> --
> Sofía Celi (aka cherenkov)
> @claucece / @cherenkov_d
> Cryptographic research and implementation at CAD: https://autonomia.digital/
> EF74 1A5F 5692 E56F 14F6  243C 3992 6144 F89D 996F
> 
> 
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls