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

[Valery Smyslov <[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

 

          Do you mean "version A and ciphersuite X"? (or ciphersuite Y, since there is no ciphersuite B).

         (Since there is some confusion with the ciphersuites (there is no ciphersuite B in your example), let's go with the version number only.)

 

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.

 

          It's obvious that any client supporting version A can join the group that was created using version A.

 

          In my scenario the external client supports only version B. So, if it were among the clients that form the group,

          then the group would have been created with the different version (since all other members support A and B and the client in question supports only B,

          the common denominator is B and they would go with it). But it wasn't. Can this client unilaterally join the group later?

          In this case the group version should change as a result of its join (I assume group policy doesn't prohibit B). 

 

          Does the protocol support this scenario?

 

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.

 

          Regards,

          Valery.

 

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