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

[Valery Smyslov <[e-mail]>]

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.