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

[Sofia <[e-mail]>]

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 ;)

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.

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.

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.

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.

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?

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