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

[Richard Barnes <[e-mail]>]

Just to recap your scenario: Suppose we have a group where:

* All members support versions (A, B) and ciphersuites (X, Y) [where A < B
and X < Y for some definition of "<"]
* The group uses version A and ciphersuite B

In that case, MLS would allow any client to join (including external join)
that supports version A and ciphersuite B -- what the members support
doesn't matter, only that the joiner supports the group's parameters.

That said, MLS provides verified information about version/ciphersuite
support to all members, and the joiner's information is visible in an
external join.  So for example, an application might implement policies
that enforce a minimum version / ciphersuite on new joins by having a
server reject KeyPackages or external joins that use the
versions/ciphersuites that are too old.  Likewise, group members could
refuse to add a new member (remove an external joiner) that doesn't meet
their requirements.

--Richard

On Wed, Sep 28, 2022 at 3:42 PM Valery Smyslov <[e-mail]>
wrote:

> Hi Richard,
>
>
>
> thank you for the explanations. One clarifying question (with trimming all
> the rest):
>
>
>
> Hi Valery,
>
>
>
> Thanks for the review. A couple of comments inline (with some trimming)...
>
>
>
> 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.
>
>
>
>           Do I get you right that the following scenarios are already
> supported by the protocol?
>
>
>
>           Some set of clients that all support version x and version y
> (where y > x) form a new group
>
>           using version y. Let this group policy allows "external joins".
> My question - can a new client
>
>           that support only version x join this group later using the
> external join mechanism?
>
>           The same question with ciphersuites - if all clients in the
> group support
>
>           ciphersuites X and Y and selected X as "the best" at the time
> the group is formed, then
>
>           can a client that only support ciphersuite Y join this group
> later using
>
>           "external join"? Note, that in both cases there is some kind of
> downgrade...
>
>
>
>           If these scenarios are supported by the protocol, then my
> concerns were extraneous.
>
>           However, it would be great if they are outlined in details in
> the document.
>
>
>
>           Regards,
>
>           Valery.
>
>
>
>
>