Subject: [MLS] ClientInitKey Ambiguity

From: Brendan McMillion <[email-masked]>
Date: Fri, 16 Aug 2019 12:51:27 -0700

Hello mls@

The definition of ClientInitKey in the spec currently has it contain
several protocol versions, ciphersuites, and public keys. However,
ClientInitKey objects are embedded into Init and Add messages, sent to many
people, and all of these people must choose the same public key from the
ClientInitKey for their ratchet tree.

Sending multiple public keys wastes bandwidth and could cause
synchronization issues, if different members choose different public keys
from the ClientInitKey. In particular, if the same ciphersuite is provided
twice, which I think is allowed.

The set of supported versions in the ClientInitKey is also an array, but it
doesn't seem to have the same 1-to-1 correspondence that the ciphersuite
and public key arrays do. Not clearly denoting which ciphersuite
corresponds to which protocol version seems like it also causes
synchronization issues.

If people agree, I'd like to open a PR changing ClientInitKey to contain
only one protocol version, selected ciphersuite, and public key. Clients
can generate many ClientInitKeys if they wish to support many versions and
ciphersuites.

---

From: Richard Barnes <[email-masked]>
Date: Sat, 17 Aug 2019 17:37:07 -0400

Hi Brendan,

I don’t think there’s an ambiguity here; IIRC, the spec requires that
public keys match ciphersuites, and that each ciphersuite appear once.  So
“the public key for the group’s ciphersuite” should be well defined.

I agree that it’s inefficient, though.

The main difference between the current scheme and your proposal is that
the full list of supported suites never appears, so the server can
downgrade a group to the lowest suite supported by its initial set of
clients.

Personally, that risk doesn’t seem awful to me, since I don’t expect a ton
of variability in client capabilities, at least in the short run.  But it
would be a different guarantee than you get out of TLS.

What do other folks think?

—Richard

On Fri, Aug 16, 2019 at 15:51 Brendan McMillion <brendan=
[email-masked]> wrote:

> The set of supported versions in the ClientInitKey is also an array, but
> it doesn't seem to have the same 1-to-1 correspondence that the ciphersuite
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: Michael Rosenberg <[email-masked]>
Date: Tue, 20 Aug 2019 11:44:58 -0400

> IIRC, the spec requires...that each ciphersuite appear once.  So “the public key for the group’s ciphersuite” should be well defined.  

I don't see this in the spec. I think this should be a requirement though: if a ciphersuite is defined in an MLS version that appears in ClientInitKey::supported_versions, it MUST appear in ClientInitKey::cipher_suites precisely once.