Re: [MLS] Artart early review of draft-ietf-mls-architecture-09

[Richard Barnes <[e-mail]>]

Hi Valery,

Thanks for the review. A couple of comments inline (with some trimming)...

On Wed, Sep 28, 2022 at 4:46 AM Valery Smyslov via Datatracker <
[e-mail]> wrote:

> 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 believe the intent here is that this document is a companion to the
protocol document, i.e., that they should be read together.  So I would be
disinclined to add more detail to the architecture.



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

Similar comment here.  These documents go together, so the architecture
will be kept up to date with the protocol.


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

I think the mechanics you're looking for are already in the protocol.  The
Capabilities element of the LeafNode describes the supported versions and
ciphersuites for each member of the group, so you can always tell whether
the version/ciphersuite in use is the best one possible.  At the beginning
of the group, this functions as downgrade protection; as the group ages and
clients update to support new things, it can highlight opportunities for
upgrade.  (Upgrade being done with the ReInit mechanism in the protocol.)
All members of the group are aware of these signals and protected from any
intermediary tampering with them.

The latter point is the important one: The protection against downgrade
here is against *intermediaries*, not group members.  The notion of "best"
is up to the application (just as for say TLS servers), thus so is the
selection of ciphersuites among those available and the timing of upgrades.

In other words, the protocol has already done all it can do.


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

This limitation is frustrating, but it's a consequence of the
cryptography.  Not impossible, but very expensive.

There is a PR open to provide more guidance in the protocol spec for
leavers: https://github.com/mlswg/mls-protocol/pull/736


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

IMO these are all application design questions, to be addressed in the
context of designing a specific DS/MLS integration.


>
> 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).
>
>
>
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>