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

[Sofía Celi <[e-mail]>]

Hi, Benjamin et al,

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

Thanks you all!

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

Yeah, I understood that as well. No worries. I can try to help on that 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.
>
> 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

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..

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

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

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

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.

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

Awesome! Thanks so much for the issue!

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

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

Thanks!
--
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