Re: [MLS] Éric Vyncke's Discuss on draft-ietf-mls-architecture-10: (with DISCUSS and COMMENT)

[Benjamin Beurdouche <[e-mail]>]

Hi Éric,

Thanks a lot for the review, please find some insights below.
I have filled https://github.com/mlswg/mls-architecture/issues/179 to keep track of all the requested changes.

Best,
Benjamin

> On 31 Jan 2023, at 11:25, Éric Vyncke via Datatracker <[e-mail]> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-mls-architecture-10: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> # Éric Vyncke, INT AD, comments for draft-ietf-mls-architecture-10
> CC @evyncke
> 
> Thank you for the work put into this document.
> 
> I find it very difficult to understand as many concepts are not explained.
> Usually, I start reading the architecture I-D before the protocol one, and this
> document does not help understanding the architecture. We could even argue
> whether the I-D is about architecture or about security considerations.


The MLS architecture document has been written using a non-conventional approach for the IETF in
the sense that it only provides a very basic set of Functional Requirements in the document.
So, the lack of precision in the description of the general architecture is "by design”.

The reason is that the WG has focused on designing a Protocol which works with many different
architectures (centralized, decentralized, with a PKI, with no PKI… ) so that different Service Providers
can use a single protocol for their use cases (secure messaging, video conferencing,
machine-to-machine, IOT, Satellite….)

However, the security and privacy guarantees that should be achieved in all these use cases
and architectures are supposed to be constant. This is why the overall document seems very centered
around a core abstract protocol and the security model instead of explaining one specific architecture.


> Please find below some blocking DISCUSS points (easy to address), some
> non-blocking COMMENT points (but replies would be appreciated even if only for
> my own education), and some nits.
> 
> Thanks to Tatuya Jinmei, the Internet directorate reviewer (at my request),
> please consider this int-dir review with one nit worth considering:
> https://datatracker.ietf.org/doc/review-ietf-mls-architecture-10-intdir-telechat-jinmei-2023-01-29/
> and as noted I share Jinmei's view about the clarity of the I-D.
> 
> Please note that Dave Lawrence is the DNS directorate reviewer (at my request)
> and you may want to consider this dnsdir review as well when Dave will complete
> the review (no need to wait for it though):
> https://datatracker.ietf.org/doc/draft-ietf-mls-architecture/reviewrequest/16998/
> 
> Special thanks to Sean Turner for the shepherd's detailed write-up including
> the WG consensus *and* the justification of the intended status.
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> ## DISCUSS
> 
> As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
> DISCUSS ballot is a request to have a discussion on the following topics:
> 
> ### Section 6
> 
> What is a `LeafNode` ? I.e., please define what it is before using the term ;-)
> Very similar issue in 5.1 for `GroupInfo`. And as noted by Jinmei "Commit" and
> "Proposal".

Ideally, this language should not even be referenced as the notion of Leaf node is
not matching the targeted level of abstraction in the protocol document.
(the notion of Tree is internal to the protocol and not visible by the application)
Credentials should be used instead and I will ensure that it is introduced properly.

Generally, the notions of Group Info, Proposal and Commit are quite general and
seem acceptable to refer to in the architecture document, I will ensure that this
terms are properly introduced by possibly adding a Terminology Section.


> ### Section 7.1
> 
> Is it appropriate for an IETF RFC (even if informal) to qualify WireGuard and
> TOR as `secure channel` ? This DISCUSS point is only to generate discussion
> among the IESG during the telechat. This discuss point will be removed anyway
> after the discussion.

We have been using standard academic terminology for secure channels which is roughly
a communication channel between two peers providing secrecy of the data in transit.

TLS or QUIC are often referred to as secure transports, so I feel it is fine to keep this
terminology, but please let me know if that is a problem, I can certainly rephrase… : )
 

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> ## COMMENTS
> 
> ### Abstract about 'scalable'
> 
> This document and its companion appear to demonstrate the security properties
> of MLS, but do they also cover the scalability ones ? E.g., in section 2, there
> is `or as large as thousands`, good number but not enough for an IETF full
> remote plenary. Later in section 5, it is `groups with tens of thousands of
> members`, i.e., a different order of magnitude.

Scalability overall depends only on a few factors
1. Network latency and allowed bandwidth
2. Computational power of the devices running the client.
3. Frequency of the group operation messages (because it causes key updates)

In terms of complexity, the design is in general linear or sub-linear in the number of users
which is a significant improvement over existing designs. It could even go to 100k or 1M users
depending on the fine tuning of those parameters. 

So it can definitely handle a full remote plenary on most devices ; )

> ### Section 2
> 
> In `The Service Provider presents ....` is it unclear to me what service it is
> about ? The MLS service or the messaging service ?

Service Provider is meant for Facebook / Signal / Wire or any entity providing
an application relying on MLS.

> Is there a reason why sometimes AS/DS acronyms are used and at other places
> their expansions are used ?

This is just a convenience to familiarize the reader with the acronyms from time to time.

> `she can use to send encrypted messages to Bob and Charlie` is the message also
> signed by Alice ? Hinted in section 3 but worth already warning the reader...

The application messages are encrypted, maced and signed, yes.

> `join an existing group;` should "(by asking to be added)" be specified ? As
> per `leave a group`.
> 
> Does the MLS group intend to extend the MLS protocol itself to support group of
> moderators ? This sounds like a basic requirement to me (as a frequent
> videoconf user/moderator).

We designed the MLS protocol so that all protocol clients have the same abilities,
however, the application using the protocol can create these functionalities and for example
say, “well, I will only accept these changes to the group if they have been made by
this specific subset of users”. 

> ### Section 4.2
> 
> Why is "Partition-tolerant" mentionned in to the classes of DS ? It seems that
> it is useless to specify as a discriminator.

I think that the idea is to mention that some infrastructure might run the protocol in a partition
tolerant fashion and that the application can handle that scenario.
This is typically not the case of centralized infrastructure.

> I find this section difficult to read, e.g., what are the "Commit" or
> "Proposal" messages ? It seems that the flow is not natural.

I’ll improve the document to better introduce these terms as requested in the DISCUSS section.

> ### Section 5.4
> 
> Perhaps a mere rendering issue, but RECOMMENDATION appears in bold and is in
> uppercase while it is not a normative 'RECOMMEND'. Strongly suggest to use
> lowercase.

I’ll look into this. Thanks.

> ## NITS
> 
> ### SEction 1
> 
> Isn't `enjoy some level of security` ambiguous or under specified ?

Vastly, yes : ) The spectrum of properties is 

> ### Section 2
> 
> Please use the Oxford comma in `Alice, Bob and Charlie`

Ack

> ## Notes
> 
> This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues.
> 
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments

Thanks for the review Éric !

Best,
Benjamin