[MLS] ClientInitKey Ambiguity
Brendan McMillion <brendan@cloudflare.com> Fri, 16 August 2019 19:51 UTC
Return-Path: <brendan@cloudflare.com>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB8D120824 for <mls@ietfa.amsl.com>; Fri, 16 Aug 2019 12:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAiKkqnTwhhY for <mls@ietfa.amsl.com>; Fri, 16 Aug 2019 12:51:42 -0700 (PDT)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4636E1200D6 for <mls@ietf.org>; Fri, 16 Aug 2019 12:51:41 -0700 (PDT)
Received: by mail-qt1-x82a.google.com with SMTP id v38so7410037qtb.0 for <mls@ietf.org>; Fri, 16 Aug 2019 12:51:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=5sI3Hoi1po77947wWAKHUgj8ZjUFpTkGdPMyNyBsngU=; b=jHZyG+Gi4zTHKLEpjXbefpjVhOsAwpUDfL5a0tHyDY+ucNqWF5FK3WEAvby9VqHh60 yPvn1gcUSKQepF7REEpbYhXgc6CQUNn6glte+vUeJuwG3ZzzWOQKm9dFf2T8j6bs63kC 3YnLFVBB+szI7Yv5zODztKfY1FvfKfrU15IfE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5sI3Hoi1po77947wWAKHUgj8ZjUFpTkGdPMyNyBsngU=; b=CVjajEMVhPGRn0QY0m1OS7qb1tIcP6DwX0OMrS9CrIIkbU6UodTY+bhz7CuWh4pO5F 7Zbx57ju0zQW+TRlGS7gVDMdKTsDi+DiYACElcABg2ipHhStwIHGTMWY0VGUeb44PFmP F7Dw2jmYirCJ1o++rL3AUsUzq44twZXOrRwrUBtoIABzeC4UZvpbv1Ld7m/aUKAp6Ult FxZHaPqSQBJ6z+fOthnfYAIJm4UaGdKTFYbklbGLT7MTihZxHCuqewyNyn5zBuYhnFwz vl9oeUtinktfNl0ejLJ6mOgTUhfnnXw9GH2KFLUQbSKesLtej3iH6Yb1hBdxFfzshZhZ mM9w==
X-Gm-Message-State: APjAAAXatE2Oc5NIadIEoy+dZuWl7ck4ot16ZVsdRxav+hwus0d8HU/2 ms6SKTw/Ty1xkCeQfSZJ4NAFWZPKj0xI8Fpncb3ySJH7OyE=
X-Google-Smtp-Source: APXvYqy47M4qYFbsDIz6bIF19zpDrkUZqBPbzVPBzIW1XMmRT9eiFXVvz/UgFPsHmXL1fe+GGEjOtHO/B7Z78sAiSBM=
X-Received: by 2002:a0c:8695:: with SMTP id 21mr3120486qvf.166.1565985098992; Fri, 16 Aug 2019 12:51:38 -0700 (PDT)
MIME-Version: 1.0
From: Brendan McMillion <brendan@cloudflare.com>
Date: Fri, 16 Aug 2019 12:51:27 -0700
Message-ID: <CABP-pSTpKR4jU1X7n8oNFoBExQzMEPBKcGQcJm1eSYsbE=p9NQ@mail.gmail.com>
To: mls@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008cc0c805904151fb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/yGdu9LPb_MkQQngdWKGkS9kuaGo>
Subject: [MLS] ClientInitKey Ambiguity
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Aug 2019 19:51:44 -0000
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] ClientInitKey Ambiguity Brendan McMillion
- Re: [MLS] ClientInitKey Ambiguity Richard Barnes
- Re: [MLS] ClientInitKey Ambiguity Michael Rosenberg