Re: [MLS] Deniability as external to the MLS protocol

Chelsea Komlo <> Thu, 22 October 2020 18:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B990D3A097E for <>; Thu, 22 Oct 2020 11:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tpQR0-aKn0uP for <>; Thu, 22 Oct 2020 11:38:32 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 585E93A097C for <>; Thu, 22 Oct 2020 11:38:32 -0700 (PDT)
Received: by with SMTP id z5so3782367ejw.7 for <>; Thu, 22 Oct 2020 11:38:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nXy0kyEkheIhxGKCb8HEfC9d3ciHao1VbsZXoQNuKEw=; b=fzDHIUi62GFUGaDZD6M2ujpVZ8EIusiXtLlhuqPHQPGktrCgObKYooLLRSnuOu+qMG osH3rsNNhUSgT5PIHMiQyF/VDjws4Uxmn6eTFpRL9JD79TZgGitEaupYDgLpAB5fXSDI UvNg0ELpv9k233PusRiANItTByxegURSK5K9s62kLFudEOM3l3fXE7yl6R/L7ugFJ1i9 zUz4Wi6CKzYEqY7jNtg0sOt+/l6YB67Rf/3CmYeB/jehcP1j7R25IlnJg1wXW1gRhIOO wYwhoYoW6viO2DJUi7E+K92Od/Yn2WCnCKcMyUHG57m5FydjhMeBXPoSvZAivEaK1zaV Z0Cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nXy0kyEkheIhxGKCb8HEfC9d3ciHao1VbsZXoQNuKEw=; b=EuP8ya9JInQUVq7WZyewQNGLNQp7CniG/NGLWfTjtX64aWOGYHbZENKt3fTnDnxBnp E+QIb9+DEElpf3qxn3IwENB3iP0cVKT0OiIqvne3/KDFUVW+xuFrSQz1w1P8iBRetrUr qUVFkf584qOGjzMZ8WWFAjAJ5kpBOi7GK3YnodkkypFBnkpGcQPJtubywgNcuXYQR3E6 jRJ42e0yQMSgDsY7d+cT+/i4BSvoLsnMooXw/onW4DH6+j0EHLn6LgzXGEq0Z3PJIkCO 5T11CDgrvTcSQZBiWGydqJ9ETjptiDOYhIu7kUVXfkLNOnl0lzzXIsHujDZGKeMWNpKX hPZQ==
X-Gm-Message-State: AOAM530IU6YkplEh3fpBs0NnhLV6zmRyWBkLeCKKOF8vVdtFWGZFMIqd qKvPovhfHOoMt9/I1vRon6e/cV62bWehArcgJfvzoQX1
X-Google-Smtp-Source: ABdhPJz5amzYVs+33eyik8KptiMyyNKefeAzaiYJpomkc6nJSbVxl0laLpAyL/9cdnI3/UPkAgDPYDpFpxuryowMa4c=
X-Received: by 2002:a17:906:2894:: with SMTP id o20mr3515362ejd.221.1603391910816; Thu, 22 Oct 2020 11:38:30 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Chelsea Komlo <>
Date: Thu, 22 Oct 2020 12:38:19 -0600
Message-ID: <>
To: Richard Barnes <>
Cc: Messaging Layer Security WG <>
Content-Type: multipart/alternative; boundary="00000000000047b2f305b246c5ad"
Archived-At: <>
Subject: Re: [MLS] Deniability as external to the MLS protocol
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Oct 2020 18:38:35 -0000

Hi Richard,

This approach of per-conversation non-attributable signing keys ensures
"conversation/participation unlinkability", which implies deniability.

This is certainly a viable option for implementations at a level above MLS,
with the caveat that it has sharp edges as nothing in MLS forces signing
keys to be used for exactly one group. Further, ensuring both async
conversations and single-use-keys may be tricky.

It would be great for future versions of MLS to think about how to move
deniability within the protocol itself, but most importantly I think it is
best to keep the core protocol simple to understand and implement. Allowing
deniability protections to be implemented at a layer above MLS seems like a
good compromise towards finalizing the first version of the protocol.


On Thu, Oct 22, 2020 at 11:50 AM Richard Barnes <> wrote:

> 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.
> Best,
> --Richard
> _______________________________________________
> MLS mailing list