Re: [MLS] ClientInitKey Ambiguity

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=
40cloudflare.com@dmarc.ietf.org> wrote:

> 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.
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>