[MLS] Use Cases for avoiding Forward Secrecy

Dave Cridland <dave@cridland.net> Wed, 28 February 2018 17:14 UTC

Return-Path: <dave@cridland.net>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 603BD1242F5 for <mls@ietfa.amsl.com>; Wed, 28 Feb 2018 09:14:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id WoYSdX5YeVMq for <mls@ietfa.amsl.com>; Wed, 28 Feb 2018 09:14:19 -0800 (PST)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 C12CE12D7F1 for <mls@ietf.org>; Wed, 28 Feb 2018 09:14:18 -0800 (PST)
Received: by mail-lf0-x22d.google.com with SMTP id y19so4631828lfd.4 for <mls@ietf.org>; Wed, 28 Feb 2018 09:14:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=dUsb+ECJfrlq+eSCCv3r4C16AffIJg/DqXdUQQ9X/tc=; b=RJzS8qzwEvlbZWD1W7IdM5GLsfvcnC5+viPcaBTZpNQMxffQ9/AWCnL+Zr05i4fMPK hKWTRjdAwL7D3bSfPrvcoHpEwmH2NqIclXr88G5UXCBynAyOqg8BR4AvfY3JRGMkXFDu Y73DXALxE7uxwwmPrCVZsYEyTPJJ3pxmuJhnc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dUsb+ECJfrlq+eSCCv3r4C16AffIJg/DqXdUQQ9X/tc=; b=WSTqqu5UtgTLCs50BEjKOu+mx7E8kXtss9F6/2evCKli2pgZfVukc/g7AOTIdgpWVD ZqejnqVYsV4sfM/ZRt9gMOwWq85xaBqTZWF6HhLi1L3i71Mk01QvnkfrquyrqsPWazPl BDuZ+WkhNkzXFHZ2T2+HGSxeFQMZFmjnp7vC9V1E3kkGKQbFQWBplchZ8Kg2GzqSP/i+ oSN4mr3bezZ0a6Oo8Yi/LUGfQgelUwPynv2Ch4W0nK5XnifxpxqgrR840hBiD5REOaYm w8VNIAXFBVp6nqcaEUQcLon+Eja3GAQEX5HJwGcM/rJRDS25rdhfYT9eEFBQWmh1aMmH ShLg==
X-Gm-Message-State: APf1xPA04OEerRt6MligC9e3eMXzizcbQcQGKa6OPAbrEaUTxBuQ2ael JZZ3gqctl5TeqSqSjRgK7ORoH5c5DU6zlSFwPA7lU1+T
X-Google-Smtp-Source: AG47ELudBw9IUcneW/zGyNhr6WRWFGC2E+Ah0+hE/Zlwb/LyqrbYdRDKmUjwiWbm9kdfRxe4OwoK/PtZ2iErthCbIJc=
X-Received: by with SMTP id 10mr14323624ljn.8.1519838056750; Wed, 28 Feb 2018 09:14:16 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 28 Feb 2018 09:14:16 -0800 (PST)
From: Dave Cridland <dave@cridland.net>
Date: Wed, 28 Feb 2018 17:14:16 +0000
Message-ID: <CAKHUCzxOwmPrpUUj6HSRMcxiXtRmT05OapeBQdRA49bSWum6yQ@mail.gmail.com>
To: mls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/b5YoQfdeFcoLYrFdxbZmdX__jWA>
Subject: [MLS] Use Cases for avoiding Forward Secrecy
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 28 Feb 2018 17:14:20 -0000

Hi folks,

While I'm really pleased to see MLS, and I generally like the idea of
Forward Secrecy, there's a couple of use cases where it might be worth
avoiding. Feel free to correct me if these are in fact possible with
Forward Secrecy. Both these relate to archival access to past

* UX - Some users (actually all of them) would like to be able to
install client software on a new device and have their historical
messages available to them. Most "business" messaging systems seem to
work this way, as well as a number of consumer-grade systems. The
nature of Forward Secrecy means that an archive would need to be held
on one device and re-sent to another through the network, which is
trickier to manage, and is reliant on multiple devices being online at
overlapping times. Alternately, the archival copy might be re-uploaded
to the server using a static encryption key, I suppose, which would
rather spoil the point.

* Retention - Many business and government deployments have mandatory
retention requirements. An example is MIKEY-SAKKE, promoted in part by
the UK Government for its own communications, which uses mandatory key
escrow to keep an archived copy of the messages accessible to the
business units involved. An advantage of the SAKKE system is that it
allows the key escrow to be offline, limiting attack opportunities.

Given the latter, for example, I could not use an MLS-based system to
discuss a tax problem with the authority, and since I'm unlikely to
have a SAKKE-based messaging client, I'm unlikely to have encrypted
messaging to my tax authority at all - which seems signficantly worse
than merely having no Forward Secrecy.

None of this is to say that Forward Secrecy should be avoided
entirely, of course.