[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.
- [MLS] Supporting Large Groups Brendan McMillion
- Re: [MLS] Supporting Large Groups Richard Barnes