Re: [MLS] Deniability -> "recording"?

Benjamin Beurdouche <benjamin.beurdouche@inria.fr> Thu, 23 January 2020 14:45 UTC

Return-Path: <benjamin.beurdouche@inria.fr>
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 D65E81200C5 for <mls@ietfa.amsl.com>; Thu, 23 Jan 2020 06:45:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 ADW83Y8rrBxx for <mls@ietfa.amsl.com>; Thu, 23 Jan 2020 06:45:35 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 9DCE312004D for <mls@ietf.org>; Thu, 23 Jan 2020 06:45:34 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.70,354,1574118000"; d="scan'208";a="432733524"
Received: from 82-64-165-115.subs.proxad.net (HELO [192.168.1.20]) ([82.64.165.115]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jan 2020 15:45:22 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Benjamin Beurdouche <benjamin.beurdouche@inria.fr>
In-Reply-To: <CAKHUCzzV1Rs+iVUYpXt7kjn+ockynCpw72Erwp3FE391Rt6VMQ@mail.gmail.com>
Date: Thu, 23 Jan 2020 15:45:21 +0100
Cc: Cas Cremers <cas.cremers@gmail.com>, ML Messaging Layer Security <mls@ietf.org>, "raphael=40wire.com@dmarc.ietf.org" <raphael=40wire.com@dmarc.ietf.org>, "jon@callas.org" <jon@callas.org>, "nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <05F0D548-5F29-4AE2-BD49-E2E559CF6E95@inria.fr>
References: <2060195243.218290.1579787145340.ref@mail.yahoo.com> <2060195243.218290.1579787145340@mail.yahoo.com> <eefe9673-37e0-d244-14c5-dd34e4256cf7@gmail.com> <CAKHUCzzV1Rs+iVUYpXt7kjn+ockynCpw72Erwp3FE391Rt6VMQ@mail.gmail.com>
To: Dave Cridland <dave@cridland.net>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/GklTAP3KHMZliLfPwArarFfsk4g>
Subject: Re: [MLS] Deniability -> "recording"?
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, 23 Jan 2020 14:45:37 -0000

> We can work around the PFS by (in effect) using MLS as a groupwise key exchange protocol and exporting a longer term key for message encryption, but if we destroy cryptographic integrity post-facto, as I assume we mean by deniability, then that makes life increasingly unpleasant for the cases where people actually want different properties.
> 
> In short, preventing various groups making use of MLS is not security first.

In general, I don’t see deniability and authentication as such a strong opposition.

But anyway, MLS is currently at a sweet spot in terms of design:
As a default, because we have such a variety of use cases for the protocol, the authentication
service is responsible for the biding between an identity and the signature key which is used
by the protocol to authenticate members whether it is in a deniable way or not.

The authors and collaborators of the working group are gonna carefully document
each security tradeoffs in the architecture document, but ultimately, since each provider
has the ability to tune the exact way to provide and verify these signing keys, I think there
is no concern to have overall. We will remain careful to allow all these use cases...

B.