[MLS] Supporting Large Groups

Brendan McMillion <brendan@cloudflare.com> Wed, 26 September 2018 20:05 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 EF5621286D9 for <mls@ietfa.amsl.com>; Wed, 26 Sep 2018 13:05:46 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 orUsTh8sYrwb for <mls@ietfa.amsl.com>; Wed, 26 Sep 2018 13:05:45 -0700 (PDT)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 5999C128CFD for <mls@ietf.org>; Wed, 26 Sep 2018 13:05:45 -0700 (PDT)
Received: by mail-ot1-x333.google.com with SMTP id e18-v6so223054oti.8 for <mls@ietf.org>; Wed, 26 Sep 2018 13:05:45 -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=IRIc24M7sp+NKqZIha/af3hTWGnNK3sl3fH8uuHQeDA=; b=FhrVWs3X3Iqva2OdSkygOGEgN5ui4fTUlb1L0ztEgCL1OF+6pcaC8Toe5c9BMUByOw DvKwv1uDyxlovfvvo30y+WqEN3xxxDx6V5cfJ6aLG6WGq7BnkrQNqRnhB9c8DTjfSTP+ /MqBgG8x7B5CeA+jvFdkGm0Fvg9VptJVydv+k=
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=IRIc24M7sp+NKqZIha/af3hTWGnNK3sl3fH8uuHQeDA=; b=CjCyoZr4x0mTgUGPQQat5str0aMYHh39jzveq9u9jwTyhVbeIN6RK2HleDr8vwkSw7 RWEioqoDKZeuF/vz9UaOS7GFLrt/grbokoDYO9CNwosUYy17wQarMMny1SYo18Q4hWfl lx3kg87hCWpOjmg4w5WC+ft8m/Pp1zxkIMxQlL8w/Jei62mpMPflGOWqzJevQW8nLzJa a+wp2LFJwXK8jFaKiACMNhPPFxaQKIyUPlMApic3ePKVJnYXlIVtx14Nwq6f8qyLFbnG zlZ69seQiDEuziupDvzBLZgjtKZMV5oWrDV/vdV7O+ezcg2u1JqSBRHWWVGd6Xcr2WBs OfsQ==
X-Gm-Message-State: ABuFfohLCIOC/AtbO46UClvE+nBXZI7QM9Q9/LOiFwifQrXxKe3nrMRc Z7a2242wmjqBLwDiWZ5TS6Kr411o/6QpjjtFNXSwlK/sAGuUOA==
X-Google-Smtp-Source: ACcGV61MUGVK4q5G6lEgR//rVylzPU8vYr+cUIKQNhA6I6yf06pezT3aXqCLQpUgfJIOez14wVc4EUiruHhStbd+B8U=
X-Received: by 2002:a9d:3437:: with SMTP id v52-v6mr5614007otb.231.1537992344182; Wed, 26 Sep 2018 13:05:44 -0700 (PDT)
MIME-Version: 1.0
From: Brendan McMillion <brendan@cloudflare.com>
Date: Wed, 26 Sep 2018 13:05:32 -0700
Message-ID: <CABP-pSReq6_SmaB_q4nm_K4Z055KJ3N+r1OqFjXeXnxmVqKCxg@mail.gmail.com>
To: mls@ietf.org
Content-Type: multipart/alternative; boundary="00000000000057bd340576cbbfd5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/vkxVHs8lI4DSPekkmD60MP4cV_M>
Subject: [MLS] Supporting Large Groups
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: Wed, 26 Sep 2018 20:05:47 -0000

Hello mls@

My current understanding of the MLS protocol is that every user must be
individually invited to every chat room that they're a member of. This has
a lot of bad usability and performance properties for the case where you
want to invite the same large set of people to several different rooms. For
example, you could think about "everyone@company.com" being invited to
rooms for "Product A", "Team B", etc. I think it would be easy enough to
address this in the standard:

Rather than only being able to add one user at a time, you could introduce
a mailing list-type concept where many people are represented by a single
email address / public key. Group membership, and therefore the group
public key, would be maintained by the same system that stores user
identity keys.

I think there are probably a lot of valid ways to construct a group public
key, so standardizing a specific construction would be less useful than
just defining the necessary properties and how it would interact with the
protocol. What makes sense to me is: groups have only init keys which are
known to all group members, and no identity keys. This means that group
members can read messages but not send them (with the exception of an
Update message). To speak in a room, a group member must first send an Add
message for themselves. They can send the Add message because they know all
of the room secrets, through their knowledge of the group init private key.

An Update message can be sent on behalf of a group to occasionally update
the group init key, without requiring any specific member of the group to
join the room. Rather than signing the message to authenticate it, they
would have to provide some evidence from the Key Store that this is really
the group's updated init key. Note that in the interest of efficiency, a
group init key would likely be semi-static and re-used between several
rooms, unlike user init keys which are only used once.

Any comments or suggestions are welcome.