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

From: Sofia <[email-masked]>
Date: Thu, 14 Feb 2019 01:05:20 -0500

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

---

From: Benjamin Beurdouche <[email-masked]>
Date: Thu, 14 Feb 2019 10:17:27 +0100

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 <[email-masked]> wrote:
> 
> Hi, everyone!
> 
> Hope you are good!
> 

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… :) 

> 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

> 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

> into account the cofactor issues.

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

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

> 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

> trying to give more structure, but I'm unsure where this is done: on the

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

> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls

---

From: Raphael Robert <[email-masked]>
Date: Thu, 14 Feb 2019 10:24:09 +0100

Hi Sofia,

Thanks for the review!
I’ll focus on your questions regarding deniability for now. 

> We are also unsure of the difference between deniability and non-repudation.

The will is definitely there to allow deniability in MLS. However since that property is quite divisive, the current status quo is that it should be optional.
In practical terms, *some* deniability could be achieved by distributing the message signing keys through a deniable channel (similar to how the sender keys concept works). In a way this puts deniability “out of scope” in the sense that the distribution of signing keys is not in the charter. To my knowledge, there is no other substantial proposal on how deniability could be achieved, but it would be great to hear more from you on that subject!

Raphael

---

From: Sofia <[email-masked]>
Date: Mon, 18 Feb 2019 17:27:42 -0500

Hi, Raphel et al,

> The will is definitely there to allow deniability in MLS. However since that
> property is quite divisive, the current status quo is that it should be optional.
> In practical terms, *some* deniability could be achieved by distributing the
> message signing keys through a deniable channel (similar to how the sender keys
> concept works). In a way this puts deniability “out of scope” in the sense
> that the distribution of signing keys is not in the charter. To my knowledge,
> there is no other substantial proposal on how deniability could be achieved,
> but it would be great to hear more from you on that subject!

Mmm... are those MAC keys for message authentication or something else?
Well, it depends in the kind of deniability you want to attain and how "strong"
it will be. I've been re-reading some of the papers of the deniability properties
for a group chat setting. I'll send the ideas and concepts :) I hope that
is useful. Maybe that can be an starting point for a discussion..

Thanks!

---

From: Sofía Celi <[email-masked]>
Date: Mon, 18 Feb 2019 17:34:05 -0500

Hi, Benjamin et al,

> Thanks a lot for the review, this is always very helpful !

Thanks you all!

> to achieve in practice but we will spend a lot of time on it… :)

Yeah, I understood that as well. No worries. I can try to help on that as well.
:)

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

I'll answer on the issue. But if it is the same mechanism used by the Signal
protocol then it probably has 'middle' forward secrecy..

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

Oh, right! I'll keep a watch on the issue ;)

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

I have putted more thoughts on the issue. This is something I can definitely
help on. Maybe I'll submit a PR around this. But manly what is confusing
right now is how actually the 'Derive-Key-Pair' func works.

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

Awesome! Thanks so much for the issue!

> be very appreciated as this review was... : )

Nice! I will surely do. Once I get more into the primitives details, I can help
on other things.

Thanks!