[MLS] Deniability as external to the MLS protocol

Richard Barnes <rlb@ipv.sx> Thu, 22 October 2020 17:50 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1DE333A09F9 for <mls@ietfa.amsl.com>; Thu, 22 Oct 2020 10:50:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nv9ODSy4pwjt for <mls@ietfa.amsl.com>; Thu, 22 Oct 2020 10:50:12 -0700 (PDT)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 88E873A09BE for <mls@ietf.org>; Thu, 22 Oct 2020 10:50:12 -0700 (PDT)
Received: by mail-qt1-x835.google.com with SMTP id c5so1801036qtw.3 for <mls@ietf.org>; Thu, 22 Oct 2020 10:50:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=YyuAJu2m1hoCDHbSeV2PTTUywkSxst33sicQ8gQXz4c=; b=1pnXL9t9duWjZs6Y13MuDQe8cl7bslebYpHmNVGDxTOk0KOwZD7pCeKg+VDDsSNXlP sZyt9HPJX2+uSTr3XP8t5VnAZ07nU/qhIEoFK997PYe4JDuVzQRrwKWh1Xu5hy8ndMu5 FESkneNpsvqeWkVukG/ROY5dYK4VQOO/TO3PeYHOBzzsLfI66GKamoxIN/WBKOWd451r NBH7QPNDrSmagJ9Q2SrC2tF477jQ3TtrRmCm27HJxzww4Akqp5OByzqCgxvigl7edivJ 44aBqLrJRlKTw8qCCwg0secPfUpgzV1+IEh4VbSCyFcjjazu6tmC8Vm3iiYhRbOtrJ+W TNnQ==
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=YyuAJu2m1hoCDHbSeV2PTTUywkSxst33sicQ8gQXz4c=; b=qR+DlCVIC3g45uNW/PedpQWxDJRHqRJj4bfxYsJ4YsRfszCqjlHLvH42fblzJAM91D FO5AZc7/YrhFqfYYU9gzok0GIkmvYT1vhgMu6ehokTWgGsvXKRGWs5vYZEKx/77rQirc zT1ipohS7ZEfwYyJ6Et2uYs+Eg0q0CYboZp9TRS2f159l2yhg4Iz54NEtJyZcnKl8M0M FxJ2f03ReB2IYPokq5l89A1o3FziK35yBoGT/UUsSvK9Au/Aye9nmjs9QBs8/+WsuXHf P3RwIspEcLdQr6+COLJ2qV/k3MyXmLfO4hSYrZB9lS1mhixggg7o9wxhzqsZt3RKeJx8 ZGWg==
X-Gm-Message-State: AOAM5326mb2IkbHMFz/NHHEpysxDy26sj8NL3lLk9FpfCxqCGgpGylhc Bgu2x94nz2CQcQ0CfQlFwJv8uEhsI8YFgqE/pZumLXdNaf7XEA==
X-Google-Smtp-Source: ABdhPJwnZHWtc4pZiUwc0LJQOot4Jowc/y6GPJsgqL1T+bTL3LdEiX8pNer2T2tv873/Fk7tDjP92AygKyTiEBjTpXk=
X-Received: by 2002:ac8:74d:: with SMTP id k13mr3109226qth.191.1603389005915; Thu, 22 Oct 2020 10:50:05 -0700 (PDT)
MIME-Version: 1.0
From: Richard Barnes <rlb@ipv.sx>
Date: Thu, 22 Oct 2020 13:49:49 -0400
Message-ID: <CAL02cgTUQLwfOAhxT94AURD6Dog_1H9=bvC6c3Nox1Q8g7Nb7g@mail.gmail.com>
To: Messaging Layer Security WG <mls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000227edc05b2461884"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/r7XG621Zg7RKj53h2hC4RhcHdn0>
Subject: [MLS] Deniability as external to the MLS protocol
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: Thu, 22 Oct 2020 17:50:14 -0000

Hey all,

Some recent and soon-to-be-proposed changes involving signatures over the
group's ratchet tree have raised concerns about the deniability of the
protocol.  I'd like to propose that we can safely punt deniability to a
different layer, and not worry about it in the core protocol.

The basic idea here is that signing keys only need to be denied to the
degree they are associated with an identity, so if the Authentication
Service is deniable, all artifacts generated by MLS are as well.

For example, supposed an application were set up in the following way:

* Signature keys are only used with a single group (thus so are KeyPackages)
* MLS credentials have no meaningful identity data (e.g., BasicCredential
with identity=H(public_key))
* Group members authenticate one another by exchanging signature public
keys over a 1:1 deniable channel (e.g., X3DH)

(Here we have instantiated a distributed, deniable Authentication Service
as a full mesh of 1:1 deniable channels.)  In this setup, as far as an
external observer knows, the whole group could have been generated by a
single participant, which seems like a not-bad definition of deniablity.
The MLS messages could be generated by anyone holding the relevant
signature private keys, and the deniable signature key distribution means
that anyone in the group could be the holder of those private keys.

This model is still compatible with things like pre-publishing KeyPackages
for asynchronous add.  You could obviously do an "add first, authenticate
when the joiner comes online" scheme.  You might also be able to do
something more proactive by pre-publishing some deniable data along with
the KeyPackage.

My goal here is to argue that there is at least one way of operating MLS in
a deniable mode, pretty much regardless of what the protocol itself does.
If this argument seems plausible to folks, it should then be safe to make
some changes that had been gated on deniability concerns:

* Updating #406 so that the GroupPublicState is signed by the member that
issues it
* Updating the path hash / parent hash scheme as recommended in Joël's
forthcoming proposal (and which I expect will look like what Benjamin and
Karthik suggested back in January)

I would also be open to adding something like the above discussion to the
architecture document, if people thought it would be useful for posterity.