Early Review of draft-ietf-mls-architecture-09
review-ietf-mls-architecture-09-artart-early-smyslov-2022-09-28-00

I am the assigned ART directorate reviewer for this document. These comments
were written primarily for the benefit of the ART area directors.  Document
editors and WG chairs should treat these comments just like any other last call
comments.

The document describes a secure group messaging architecture. It also gives
recommendations for building group messaging systems.

General notes.

The document is well written and easy to read. However, I believe that the
architecture part of the document (up too Section 5) is too concise and
provides only very high level view. I believe the document would benefit if
more details were provided (e.g the description of double ratchet as the
cryptographic foundation of the MLS protocol, what is commit message and
proposal message, etc.)

I also think that the part of the document that describes functional
requirements is not generic enough and is written having the current version of
the MLS protocol in mind (it contains references to the internals of the
current protocol version, like LeafNode, external_senders, external_pub,
application_id, required_capabilities, etc., which may change or go away in the
next version). I believe that references to the concrete protocol internals
should be avoided, or these internals should be explained.

Issues.

1. Section 5.10 describes the compatibility with future Versions of MLS. In
particular it states:

   When multiple versions of MLS
   are available, the negotiation protocol guarantees that the version
   agreed upon will be the highest version supported in common by the group.

and

   In MLS 1.0, the creator of the group is responsible for selecting the
   best ciphersuite supported across clients.

I think this is problematic for the clients that join group later. Consider the
situation when a newer version of the protocol is available and some clients
are upgraded, but most are not yet. If the upgraded clients (that support both
versions) form a new group, then they select the highest version of the
protocol. After that no other clients, that are not yet upgraded (which still
form majority), can join this group. The same situation is with ciphersuites
(and it is unclear what is "the best ciphersuite", how to compare them).

I think there must be an option for the group in situation when all the members
support several protocol versions (or several ciphersuites) to change the
version (or ciphersite) on the fly (if this is ever possible and doesn't lead
to the degradation of security) if incoming clients don't support the currently
selected ones. This should also include "external joins", probably the
published information about the group should be constructed in such a way that
clients having different capabilities may read it.

I understand that this would complicate the protocol, but otherwise its
usability would suffer.

2. Section 5.1 describes membership changes. In particular, it states (at least
as I read it), that there is no way for a member to unilaterally leave the
group; they must be removed by a remaining member.

I find this limitation very frustrating. I believe, that any member should
always have a possibility to leave the group, otherwise the group starts
looking like a sect - one may freely enter, but can never leave at their will,
unless authorised by other members. In my understanding this limitation follows
from the cryptographic construction of the MLS protocol. If this is the case,
then more recommendations should be given how the applications can deal with
this limitation, so that users retain the right to leave - e.g. drop all
incoming messages, don't send updates etc. Of course these are all protocol
hacks...

3. It is not clear from the document (at least for me), whether the type of DS
(Strongly Consistent or Eventually Consistent) is tied to the the clients that
use it. It is clear that clients behave differently with different types of DS.
But the described architecture is highly flexible and can accommodate different
types of DS. My question - can the type of DS change for the existing group
(e.g. the operator upgrades the DS software and the new version provides
different capabilities)? In this case all the clients should be able to learn
the current type of DS and should always support both types.

Nits.

1. There must not be references in an abstract. I would also recommend to make
the abstract shorter (as per IESG recommendations, that an abstract should be
one or two paras in length).

2. The document contains BCP14 words, but doesn't contain references to RFC
2119 and 8174. In addition, the document contains several instances of the word
"*RECOMMENDATION:*". I believe the uppercase words are reserved for BCP14, but
this is not BCP14 word. I think it would be better to explain this word in the
newly added section (in particular, what is the part of the system these
recommendations should be applied to). In addition there are both
"*RECOMMENDATION:*" and "** RECOMMENDATION:**". Is it just a typo or does
double asterisks make the recommendation stronger?

3. Section 4.2 is a bit inconsistent with Section 6 with regard to the message
delivery only to specific clients. The former mentions Welcome message as
an example of this necessity (so I assume that some other messages can also be
delivered only to specific clients), while the latter mentions only Welcome
messages, with no "e.g." (so I assume that only these messages can be delivered
only to specific clients).

4. There are two "Informative References" sections - 8 and 10.2. I suggest to
move all the content of Section 8 to Section 10.2 (and also change appearance
to [XXXX]).

5. Section 7.1 states:

   Any secure channel can be used as a transport layer to protect MLS
   messages such as QUIC, TLS, WireGuard or TOR.

I read this as a requirement that only secure transport protocols may be used
for MLS messages. However, later in this section there are assumptions that
insecure transport may also be used (although not recommended). I think this is
inconsistent - if only secure transport are allowed, then there is no point to
discuss using of insecure one (other than providing some reasoning for the
requirement).