Re: [MLS] Proposals for handling concurrent messages

"M.A.L. Weidner" <malw2@cam.ac.uk> Sat, 23 March 2019 18:59 UTC

Return-Path: <malw2@cam.ac.uk>
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 852FD12D4EA for <mls@ietfa.amsl.com>; Sat, 23 Mar 2019 11:59:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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=universityofcambridgecloud.onmicrosoft.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 jKe7cJyazpKu for <mls@ietfa.amsl.com>; Sat, 23 Mar 2019 11:59:35 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40139.outbound.protection.outlook.com [40.107.4.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D53012D84C for <mls@ietf.org>; Sat, 23 Mar 2019 11:59:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=UniversityOfCambridgeCloud.onmicrosoft.com; s=selector1-cam-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dsJFVQP3ashSOyAtVDV8JIrlH3kQwYITC8IQlXAHecs=; b=AaIsQRnCF0yN1CisU0lG5Hy/dnyMfGkUwde9p1MRx5OTPh0TurjKvh5uxtVydWvT3ayWmq2dtQnBREC+IaqclOGvAKS58KKJw9PhNqY+OwbAMmEXsKEPClMxU/1EcH493bPrVtypop8DgPVP+8mQXm+VheQDsAidtG8ilUdYDRs=
Received: from DB6PR0701MB2566.eurprd07.prod.outlook.com (10.169.215.142) by DB6PR0701MB2264.eurprd07.prod.outlook.com (10.168.58.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.15; Sat, 23 Mar 2019 18:59:32 +0000
Received: from DB6PR0701MB2566.eurprd07.prod.outlook.com ([fe80::6814:77d6:db25:b321]) by DB6PR0701MB2566.eurprd07.prod.outlook.com ([fe80::6814:77d6:db25:b321%11]) with mapi id 15.20.1750.010; Sat, 23 Mar 2019 18:59:32 +0000
From: "M.A.L. Weidner" <malw2@cam.ac.uk>
To: Matthew Hodgson <matthew@matrix.org>
CC: Richard Barnes <rlb@ipv.sx>, "mls@ietf.org" <mls@ietf.org>, "karthik.bhargavan@gmail.com" <karthik.bhargavan@gmail.com>
Thread-Topic: [MLS] Proposals for handling concurrent messages
Thread-Index: AQHU3qO7vFsPft27yE62tRLT8TpCKw==
Date: Sat, 23 Mar 2019 18:59:32 +0000
Message-ID: <CADSARUuoyAECjSEbEoVcQjjdxdSqg3JtVoaE94-90Y6UFisctg@mail.gmail.com>
References: <CADSARUtSRJGW=z=9Spi=D87mOG34NCTswEcQMeeftv9x6gathQ@mail.gmail.com> <CAL02cgQ-2gR9VK=_LthYO7fSGnDoaYei6dhuFjjdZQ7-aMSBaA@mail.gmail.com> <252D1744-22C1-49DE-84A2-12EDF0419663@matrix.org>
In-Reply-To: <252D1744-22C1-49DE-84A2-12EDF0419663@matrix.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: AM6PR0402CA0003.eurprd04.prod.outlook.com (2603:10a6:209::16) To DB6PR0701MB2566.eurprd07.prod.outlook.com (2603:10a6:4:24::14)
x-ms-exchange-messagesentrepresentingtype: 1
x-gm-message-state: APjAAAUwSEJDT5zpNSPweHoDkyW7PZceNlEzrZUtroR17rsIwHqT6Nb0 IRX7+o3ciB9y1nY9vIHzz47VNm3gZLNMEMbwl60=
x-google-smtp-source: APXvYqyyBxHL2a1tMkVGED2qC2UnXfaBG2MjUX1n5Itiu/tcERuSqUD7fYKP+sguMlIBsjT5u6m0BG8vw6uE5QqXnAw=
x-received: by 2002:a5d:670b:: with SMTP id o11mr450306wru.125.1553367236416; Sat, 23 Mar 2019 11:53:56 -0700 (PDT)
x-gmail-original-message-id: <CADSARUuoyAECjSEbEoVcQjjdxdSqg3JtVoaE94-90Y6UFisctg@mail.gmail.com>
x-originating-ip: [209.85.221.53]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6ce86d38-10f2-4bcd-0b43-08d6afc1af52
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:DB6PR0701MB2264;
x-ms-traffictypediagnostic: DB6PR0701MB2264:
x-microsoft-antispam-prvs: <DB6PR0701MB2264132B57962F66F795DCE1AC5C0@DB6PR0701MB2264.eurprd07.prod.outlook.com>
x-forefront-prvs: 0985DA2459
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39850400004)(396003)(376002)(136003)(199004)(189003)(51914003)(66574012)(106356001)(386003)(81156014)(107886003)(786003)(5660300002)(5070765005)(8676002)(55446002)(102836004)(6506007)(81166006)(15650500001)(316002)(14444005)(6116002)(61726006)(7736002)(99286004)(305945005)(25786009)(256004)(53546011)(8936002)(498394004)(97736004)(3846002)(68736007)(61266001)(9686003)(476003)(54896002)(478600001)(6512007)(446003)(4326008)(11346002)(2906002)(74482002)(236005)(6486002)(14454004)(95326003)(6436002)(53936002)(52116002)(71190400001)(6862004)(229853002)(186003)(105586002)(26005)(561944003)(6346003)(54906003)(71200400001)(486006)(76176011)(86362001)(6246003)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2264; H:DB6PR0701MB2566.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cam.ac.uk does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=malw2@cam.ac.uk;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: pAESDKZ8N52BTltgyaxXNc4MLmHknj2z9E9l17Vafglacq1aC39vdSSdwvMiUAKnDg3yXd8MU1iTTHTK16pmtZVQ8xAqrZtB92hiB6Q4C9EhWvTw222K9BR+6s1B7HI5CQkNNXqF+zo1wZhe4e1uXu/HElcv0rcY5KEcVqeMRv6kx7tqoR1LRu3f2kCWSArkUnHncJCzK9I7hDfRAA50PdHjSNSjhckSb7Fk98lC3PjvOOVUiPV/2EhEhg+bdUPkfLmcO7yHO6RAz2QUOk1NYrsPkWxgAgrW2jx7+JhBfGg2Hkm+dA4M8+lnm+ixjIG3jPn8PLHPXfrjRJhvmUYLEphQwSP3hIM0QS1FRY49tPFHYHqqb9iLhKaGgDj7ccq9sOsxF0/XKV/dr0soUAjeA1M7jF3ejOx6VHw/90SQec4=
Content-Type: multipart/alternative; boundary="_000_CADSARUuoyAECjSEbEoVcQjjdxdSqg3JtVoaE9490Y6UFisctgmailg_"
MIME-Version: 1.0
X-OriginatorOrg: cam.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ce86d38-10f2-4bcd-0b43-08d6afc1af52
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2019 18:59:32.7314 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 49a50445-bdfa-4b79-ade3-547b4f3986e9
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2264
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/uhGVFQXgx7hD6GuPqPfhsOSZgak>
Subject: Re: [MLS] Proposals for handling concurrent messages
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: Sat, 23 Mar 2019 18:59:40 -0000

Dear MLS Working Group,

Thanks for the feedback.  Some responses:

On Fri, Mar 22, 2019 at 5:00 AM Karthikeyan Bhargavan <karthik.bhargavan@gmail.com<mailto:karthik.bhargavan@gmail.com>> wrote:
Now, what is the situation with causal TreeKEM? As far as I see, it also does not protect concurrent updates against the compromise of both old keys?
And the guarantees of definition 4.1 appear only to hold for causally ordered updates, not for concurrent ones?
Is that the case? If so, I’d like to see a crisper distinction between the extra guarantees that Causal TreeKEM provides over vanilla TreeKEM.

For concurrent updates by a subgroup of users who have all been compromised, I believe Causal TreeKEM gets the same guarantees as vanilla TreeKEM.  For example, if A and B are compromised and then update concurrently, we must wait for a causally dependent update by some user in the smallest subtree containing them, as you explained for the vanilla case.  (Definition 4.1 doesn't incorporate these guarantees because I was not aware of them, so thanks for bringing them up!)

The main advantage of Causal TreeKEM comes when there are compromised and non-compromised users updating concurrently.  For example, if one of A, B, C, etc. are compromised and they all update concurrently, then the whole state is healed in Causal TreeKEM, whereas in vanilla TreeKEM this is only true if the compromised user "wins" at every conflicted node.

For another example, suppose a group partitions into two subgroups S and T, which come back together later, merging their update sets.  This could happen in an application that lets users communicate through a LAN or ad-hoc network even if they are disconnected from the global Internet, as in Haggle [1] or delay-tolerant networking.  If some users in S are compromised and then heal before re-merging with T (perhaps S is Internet-connected and thus exposed to malware while T is not), then in Causal TreeKEM, S will still be healed after the merge.  In vanilla TreeKEM, this is only true if S's updates "win" over T's updates.

I think if we want concurrent updates to heal all updating users, we need some sort of "k-party Diffie-Hellman", which is an open cryptographic problem for k > 3.  I suppose we could accomplish this by replacing conflicted nodes with blanks during concurrent updates, at the cost of increased message sizes later (devolving to O(n)-size key updates if everyone updates concurrently).

On Fri, Mar 22, 2019 at 11:17 PM Matthew Hodgson <matthew@matrix.org<mailto:matthew@matrix.org>> wrote:
On the Matrix side we are still very much hoping that MLS will somehow support reduced synchronisation, as otherwise the sequencing of membership changes acts as a very undesirable centralising force when communicating in otherwise decentralised groups. The below approach seems quite promising and from our perspective could merit picking curves which support it.

Now that you mention this, I noticed that for the proposals to make Adds and Removes concurrency-friendly, we actually don't need special curves.  For Adds, we only need to combine *root* secrets in an associative and commutative way, not all node key pairs.  This can be done using xor, since the root only has a secret binary string, not an asymmetric key pair.  Concurrent Removes don't require any key combining at all.  So perhaps these parts of Causal TreeKEM are worth considering independent of the proposal for concurrent updates.

On 20 Mar 2019, at 15:23, Richard Barnes <rlb@ipv.sx<mailto:rlb@ipv.sx>> wrote:
That would rule out X25519/X448, but I'm told that the Ristretto adaptation of those curves would work.
[...] I would be interested to hear folks' thoughts on whether the benefits of reduced synchronization would be worth the costs of limiting DH group selection (either old ECDH or new stuff without a lot of implementation).

Thanks for this, I'll check Ristretto out.  One related concern I have is that I have not yet found any mainstream post-quantum crypto proposals that support key combining.

Best,
Matthew Weidner

[1] Jing Su, James Scott, Pan Hui, Jon Crowcroft, Eyal De Lara, Christophe Diot, Ashvin Goel, Meng How Lim, and Eben Upton. 2007. Haggle: seamless networking for mobile applications. In Proceedings of the 9th international conference on Ubiquitous computing (UbiComp '07), John Krumm, Gregory D. Abowd, Aruna Seneviratne, and Thomas Strang (Eds.). Springer-Verlag, Berlin, Heidelberg, 391-408.