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

Raphael Robert <raphael@wire.com> Thu, 23 January 2020 16:31 UTC

Return-Path: <raphael@wire.com>
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 578181208DC for <mls@ietfa.amsl.com>; Thu, 23 Jan 2020 08:31:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wire-com.20150623.gappssmtp.com
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 vMCmq8vN4FK7 for <mls@ietfa.amsl.com>; Thu, 23 Jan 2020 08:31:32 -0800 (PST)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 DDE631208DB for <mls@ietf.org>; Thu, 23 Jan 2020 08:31:31 -0800 (PST)
Received: by mail-wr1-x430.google.com with SMTP id w15so3814533wru.4 for <mls@ietf.org>; Thu, 23 Jan 2020 08:31:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wire-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ntrIWDiTrLxgjJ+dSxRAK8jLN65VujpGIaUNIyv3/08=; b=I/ZMG2nb+fGhytuUi5J9FuvRDkoX3bUM2lqEi8zZDFr9w2w+pcUyTh7MvQu0Tc3PfI h+iq4tRmRGaQj/zK766AHanU1XpyUA2qYqEpIe4bfjw1lkxeiX5tlyWWejGcWS2XNkgA CzSicYxEvzJA6Ylk1Wo1whfiOhKYJTL3uyDqBIxdzI6+jfFJ4ULDjD5bODkRrnFSHBRY myqYm5qkutPYyKZLySSQGGSbr0YEComOdeqj5UT1iI/GpnRXmv1E8ujvS/k5Rnrr9BXa Tbwsi03GaP4z+R1mPWGnNLx7WG9mGJm5ItmnBUPc6Spnhxx3PRPpZXxO49XhvByHi1NY UVIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ntrIWDiTrLxgjJ+dSxRAK8jLN65VujpGIaUNIyv3/08=; b=GGcEZg7M6xEKkv6eYVnk06UBClm3G46+XznMFubJibjvJPMtUYUZ6cF/kQqRBQvh8Q X4kCi3QkqkTddX9A2WpYZYPCyjQqQ0mG4xvQsg7p/BVUZHIPLa/YD3v6mEdlhaIq8nKN hJLUmY2vyLvV+I55202EZ03afFi+q9+nh6ThDgBtQ7rvLQCLkjghsi5SyxcvGCPVQjsm vjdm3lrPWEXzMEDx5Q6g7EPjcMbIxelJRCHVlI0KDCLVUTHPIMLRg8gwdI1Ghd6Waw8V MoWOPLUUUt6619tapfp2a3Kq48aje7i7EcAh/zX77fmqnIxFBGxLfe6OEjx/ATZK4hHQ 8vSA==
X-Gm-Message-State: APjAAAWtsEtIfcWB1Rz71wH95K4KJyjLywbVrDd0icZeW55f/0rfRZlI wszrExf5s7CHful3rzZ+o9ip7A==
X-Google-Smtp-Source: APXvYqyh/8lgQgVry6maN0C/X9w6NbTP+5PAtgE9jn7HtbyDGpqAFQzFBkFkGVNc3FYarBVheTbniQ==
X-Received: by 2002:adf:e5cf:: with SMTP id a15mr17919894wrn.140.1579797090198; Thu, 23 Jan 2020 08:31:30 -0800 (PST)
Received: from rmbp.wire.local (h-62.96.148.44.host.de.colt.net. [62.96.148.44]) by smtp.gmail.com with ESMTPSA id t8sm3727153wrp.69.2020.01.23.08.31.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jan 2020 08:31:29 -0800 (PST)
From: Raphael Robert <raphael@wire.com>
Message-Id: <6B91E4EE-3768-40AF-A783-D6443BD7360C@wire.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5F21B58F-344E-491F-8D4D-5E94F9782B72"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Thu, 23 Jan 2020 17:31:28 +0100
In-Reply-To: <AE3415A4-B8C3-443E-AD5E-0FFF26169156@datashrine.de>
Cc: Dave Cridland <dave@cridland.net>, mls@ietf.org
To: Konrad Kohbrok <Konrad.kohbrok@datashrine.de>
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> <AE3415A4-B8C3-443E-AD5E-0FFF26169156@datashrine.de>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/lAvvx8XtXZ7yCbjapw1JPUoMcG0>
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 16:31:34 -0000

It seems there is some confusion around the properties. Deniability has always been considered as an optional property, this is clearly stated in the architecture document:

"As described in {{client-compromise}}, MLS provides strong authentication within a group, such that a group member cannot send a message that appears to be from another group member. Additionally, some services require that a recipient be able to prove to the messaging service that a message was sent by a given client, in order to report abuse. MLS supports both of these use cases. In some deployments, these services are provided by mechanisms which allow the receiver to prove a message's origin to a third party (this if often called "non-repudiation"), but it should also be possible to operate MLS in a "deniable" mode where such proof is not possible.”

This means that for use cases where deniability is not required or even allowed (perhaps because of compliance rules in certain industries) vendors can simply chose to not use the deniable mode of MLS.

As Konrad mentioned, FS is not optional and at the core of MLS. For use cases where FS is not desired for actual application messages and instead you want a long term symmetric key, MLS can be used to distribute this key securely among members. These use cases would require a (rather thin) layer on top of MLS that handles symmetric encryption/decryption.

Raphael

> On 23 Jan 2020, at 16:47, Konrad Kohbrok <Konrad.kohbrok@datashrine.de> wrote:
> 
> 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 <mailto: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>
> > <mailto: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 <mailto:MLS@ietf.org>
> > https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>
> > 
> 
> _______________________________________________
> MLS mailing list
> MLS@ietf.org <mailto:MLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/mls <https://www.ietf.org/mailman/listinfo/mls>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls