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

Konrad Kohbrok <Konrad.kohbrok@datashrine.de> Thu, 23 January 2020 15:47 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 4ABEC120852 for <mls@ietfa.amsl.com>; Thu, 23 Jan 2020 07:47:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 5SJlU9SZPpCz for <mls@ietfa.amsl.com>; Thu, 23 Jan 2020 07:47:29 -0800 (PST)
Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [IPv6:2001:67c:2050::465:102]) (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 8E63A120845 for <mls@ietf.org>; Thu, 23 Jan 2020 07:47:27 -0800 (PST)
Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 483RVP5HVKzKmmJ; Thu, 23 Jan 2020 16:47:25 +0100 (CET)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter05.heinlein-hosting.de (spamfilter05.heinlein-hosting.de [80.241.56.123]) (amavisd-new, port 10030) with ESMTP id e5QferuEJKjF; Thu, 23 Jan 2020 16:47:22 +0100 (CET)
Date: Thu, 23 Jan 2020 16:47:16 +0100
In-Reply-To: <CAKHUCzyQ9N1179j0OZX9HQiYwqKwt2TJoZBpo0YfO-WDB8OdPA@mail.gmail.com>
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> <be7679c1-ec38-f878-98ab-b8ba4eb8f198@datashrine.de> <CAKHUCzyQ9N1179j0OZX9HQiYwqKwt2TJoZBpo0YfO-WDB8OdPA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----RLS4RAOYPOEYA7EJ2Z7P6OHP0023I0"
Content-Transfer-Encoding: 7bit
To: Dave Cridland <dave@cridland.net>
CC: mls@ietf.org
From: Konrad Kohbrok <Konrad.kohbrok@datashrine.de>
Message-ID: <AE3415A4-B8C3-443E-AD5E-0FFF26169156@datashrine.de>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/LiogX4WiMKZIsu4V6yLb4sm_lNg>
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 15:47:35 -0000

The record keeping doesn't have to be in the nurse's phone. You can simply mandate that by default a recording service is added to every conversation. That service can run on a well-secured server.

Implementing or even deploying MLS is certainly not going to be a trivial task. However, I would argue that running your own message encryption on top of MLS (which I can't imagine why you would want that, see above) is more hassle than simply signing messages on top of MLS.

Konrad

Am 23. Januar 2020 16:35:48 MEZ schrieb Dave Cridland <dave@cridland.net>et>:
>On Thu, 23 Jan 2020 at 14:55, Konrad Kohbrok
><konrad.kohbrok@datashrine.de>
>wrote:
>
>> Hi Dave,
>>
>> I'm not sure, I understand your use-case here.
>>
>>
>I work for Pando, doing clinical messaging within the NHS in the UK,
>and
>elsewhere. Quite happy for the NHS to read doctors' and nurses'
>messages
>about patients, less happy for us to be exposed or for anyone who picks
>up
>a nurse's phone.
>
>
>> 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.
>>
>>
>We can't, actually, but as I say we can export a stable key for message
>encryption at each epoch so we're covered.
>
>(We cannot keep a log of the plaintexts since that would place
>persistent
>plaintext data on the user devices which would be problematic for us,
>since
>it's patient data).
>
>
>> 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.
>>
>
>Yes, that would probably work.
>
>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.
>>
>
>Almost certainly; though this is an ever-increasing number of hoops to
>jump
>through. My concern is that baking in a very particular definition of
>"security" runs the risk that it either outright prevents the use in
>some
>cases, or simply prices people out of the market in technical knowledge
>terms.
>
>I am already going to end up writing much more cryptographic code than
>I'd
>like to use MLS. Writing more doesn't fill me with confidence.
>
>
>>
>> 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
>> >
>>
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/mls
>>