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

Konrad Kohbrok <konrad.kohbrok@datashrine.de> Thu, 23 January 2020 14:55 UTC

Return-Path: <konrad.kohbrok@datashrine.de>
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 12F2D12020A for <mls@ietfa.amsl.com>; Thu, 23 Jan 2020 06:55:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 qeQWcrEF6utr for <mls@ietfa.amsl.com>; Thu, 23 Jan 2020 06:55:26 -0800 (PST)
Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) (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 A791B12013B for <mls@ietf.org>; Thu, 23 Jan 2020 06:55:26 -0800 (PST)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 483QLN4prqzQlJk for <mls@ietf.org>; Thu, 23 Jan 2020 15:55:24 +0100 (CET)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter02.heinlein-hosting.de (spamfilter02.heinlein-hosting.de [80.241.56.116]) (amavisd-new, port 10030) with ESMTP id 4eL6Vm_EomCv for <mls@ietf.org>; Thu, 23 Jan 2020 15:55:19 +0100 (CET)
To: mls@ietf.org
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>
From: Konrad Kohbrok <konrad.kohbrok@datashrine.de>
Message-ID: <be7679c1-ec38-f878-98ab-b8ba4eb8f198@datashrine.de>
Date: Thu, 23 Jan 2020 15:55:18 +0100
MIME-Version: 1.0
In-Reply-To: <CAKHUCzzV1Rs+iVUYpXt7kjn+ockynCpw72Erwp3FE391Rt6VMQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/WMCkw1ksSRwvlzz9DWiI14QDsTs>
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:55:29 -0000

Hi Dave,

I'm not sure, I understand your use-case here.

Regarding FS: Any participant is free to just keep a log of the plaintexts, thus
circumventing any FS guarantee. If you want to log the keys, any party can do
that as well. If I'm not mistaken could also simply opt not to use an RTreeKEM
ciphersuite and never update the recording party's leaf key.

Regarding deniability: Similarly, any member of a group can simply sign their
messages using their static identity key at the application layer. This would
effectively destroy deniability, but it is up to the application to make that
decision.

I guess my point is that destroying deniability (and FS) at the application
layer is easier then getting it if it is not built into the protocol in the
first place.

Cheers,
Konrad

On 23.01.20 15:30, Dave Cridland wrote:
> 
> 
> On Thu, 23 Jan 2020 at 13:59, Cas Cremers <cas.cremers@gmail.com
> <mailto:cas.cremers@gmail.com>> wrote:
> 
>     We're aiming for security first, I think.
> 
> 
> If we mandate deniability and mandate PFS, then the risk is that the threat
> model ends up less applicable.
> 
> 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.
> 
> Dave.
> 
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>