[MLS] Removing redundant ciphertexts in commits

Jost Daniel <dajost@inf.ethz.ch> Mon, 21 September 2020 07:37 UTC

Return-Path: <dajost@inf.ethz.ch>
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 6DD383A08BD for <mls@ietfa.amsl.com>; Mon, 21 Sep 2020 00:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 YRTUtZsR7hEH for <mls@ietfa.amsl.com>; Mon, 21 Sep 2020 00:37:26 -0700 (PDT)
Received: from mailg110.ethz.ch (mailg110.ethz.ch [IPv6:2001:67c:10ec:5605::21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7418D3A08C3 for <mls@ietf.org>; Mon, 21 Sep 2020 00:37:25 -0700 (PDT)
Received: from mailm114.d.ethz.ch (2001:67c:10ec:5602::26) by mailg110.ethz.ch (2001:67c:10ec:5605::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Mon, 21 Sep 2020 09:37:14 +0200
Received: from mailm214.d.ethz.ch (2001:67c:10ec:5603::28) by mailm114.d.ethz.ch (2001:67c:10ec:5602::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2044.4; Mon, 21 Sep 2020 09:37:21 +0200
Received: from mailm214.d.ethz.ch ([fe80::18d4:d750:ea54:d4cb]) by mailm214.d.ethz.ch ([fe80::18d4:d750:ea54:d4cb%4]) with mapi id 15.01.2044.004; Mon, 21 Sep 2020 09:37:21 +0200
From: Jost Daniel <dajost@inf.ethz.ch>
To: "mls@ietf.org" <mls@ietf.org>
Thread-Topic: Removing redundant ciphertexts in commits
Thread-Index: AdaP6fiZrnLmzMpRSA2xC/mKjaKQrw==
Date: Mon, 21 Sep 2020 07:37:21 +0000
Message-ID: <eb52dca7acba43d288ecf60a233b7e29@inf.ethz.ch>
Accept-Language: de-CH, de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [80.218.67.252]
x-tm-snts-smtp: B809C3F4C45B735259B873752E46683BEC66F4575C602DB8BBC2BE4BD84A5D682000:8
Content-Type: multipart/alternative; boundary="_000_eb52dca7acba43d288ecf60a233b7e29infethzch_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/S1imPYG9aZL-mEiYWGg4KjIWFN0>
X-Mailman-Approved-At: Tue, 22 Sep 2020 06:49:08 -0700
Subject: [MLS] Removing redundant ciphertexts in commits
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: Mon, 21 Sep 2020 07:38:39 -0000

Hi all,

When working on our analysis of the standard with Joël Alwen and Marta Mularczyk, we noted some inefficiencies around commit messages.

According to our understanding of the draft, UpdatePath contains encryptions for newly added group members. More concretely, the draft states "If populating the path field: Create a UpdatePath using the new tree (which includes any new members)" and in Section 7.7 "The number of ciphertexts in the encrypted_path_secret vector MUST be equal to the length of the resolution of the corresponding copath node." However, at this point, the resolution will already contain the freshly added leaves via the unmerged_leaves list.

First, this wastes bandwidth and computation as the commit message is not intended to be received by parties being welcomed. Second, this poses an, albeit small, additional attack scenario where an attacker gets hold of the freshly added party's decryption key but not the welcome message (that may have been communicated over a secure out-of-band channel).

One potential solution would be to explicitly exclude freshly added parties from the resolution in that step, at the cost of some additional book-keeping. Of course we are open to suggestions if anybody has a better idea. If not, we are obviously happy to draft a PR.

Best,
Daniel