Re: [MLS] ClientInitKey Ambiguity

Richard Barnes <> Sat, 17 August 2019 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42A97120164 for <>; Sat, 17 Aug 2019 14:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DOSqY3wc68mU for <>; Sat, 17 Aug 2019 14:37:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA593120118 for <>; Sat, 17 Aug 2019 14:37:19 -0700 (PDT)
Received: by with SMTP id q10so3732416oij.0 for <>; Sat, 17 Aug 2019 14:37:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j4B++2G67chkhTvvpVde+2nbUqlsEbfIidUPJjvTryM=; b=WOT/JC+b3X0jJsBW2ooSZ9vrngEnpAJWjp/DKYmK3FekV2OxifQZ8nmLZW+ccfoZPk FQBfr+ji1qT2nH9q+DxBT0yMqXck37qpP93DGzCGP6CyLKum2pdVBS76T9wa5JJay5rB P8t6PFbgdJEueCA+Lagm2vWkEDPeOhx1TBVXZ8Pvc2Fjn7W5++VZGPR3aLXBSFwpGo3E VPKWtgEJ3jdu9hAeFWzUnSsaFGoQLiFMcP9863tcX5AR7N8YAxWphxwanlVDq3VHgjUC Ic3u4BPgmVPuX0Tat69j2/nqUYHsHqNwhMRrNhKCo/TPl94TWWh9k8vUoD/fJtcaiZ5+ /l0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j4B++2G67chkhTvvpVde+2nbUqlsEbfIidUPJjvTryM=; b=sNirbo5aevxw0N4zkoksYhRgm01oQYWI5z0WfwvLOBAO4GLlWpd0akioSKyH3IEuXi R9/aGH6oP5Yiu4MVRu4FMxMzsEXpwhXWBjFum+/mrr1MA644e+B6hWHVVXKSi7aH0kOO KlH5R6Xkkv5uRx1FyIWBTOxuaBYQJ0jERINEES5vcJXLhkb35AWmqvs80RxUFNGkXFnw X6wE8BvJIaTtl3C5NKHHlwOrvszdTGEqraXxFLIc8d+nRfsM63jPOdqEdZNoqLavBVSU 7x7CCsSL/2bndAlxpIa2KKHmGHlF1jui9qpsCXKImFp6VRR8B5o/xTeNsJy1qPlxd9EO dQBg==
X-Gm-Message-State: APjAAAWET9vuI4ek6UBurXwCWGYR04Xw9VWh9EAs9Jj1h/1TiJ/6gi8C 7ZCTa/dXtSncJV1+uvQcjl3zOcG1/lmRHTZGte5BKg==
X-Google-Smtp-Source: APXvYqzYipJQMdspU4ntzajYfEyx6g1Vx+RVwt0c3Zzw/XRljbBLHpXZ/tDMi9MlkM315Th1bx9z82VAycvOzy//yvA=
X-Received: by 2002:aca:d08:: with SMTP id 8mr8660844oin.51.1566077838755; Sat, 17 Aug 2019 14:37:18 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Richard Barnes <>
Date: Sat, 17 Aug 2019 17:37:07 -0400
Message-ID: <>
To: Brendan McMillion <>
Content-Type: multipart/alternative; boundary="00000000000045200b059056e984"
Archived-At: <>
Subject: Re: [MLS] ClientInitKey Ambiguity
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 17 Aug 2019 21:37:22 -0000

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

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?


On Fri, Aug 16, 2019 at 15:51 Brendan McMillion <brendan=> 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