Re: [MLS] Use Cases for avoiding Forward Secrecy

Phillip Hallam-Baker <> Wed, 28 February 2018 23:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CC521270A7 for <>; Wed, 28 Feb 2018 15:26:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PhfW5m1bHgPG for <>; Wed, 28 Feb 2018 15:25:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB411127058 for <>; Wed, 28 Feb 2018 15:25:59 -0800 (PST)
Received: by with SMTP id m22so3886268otf.10 for <>; Wed, 28 Feb 2018 15:25:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=S9Qgko4eEaYlY03jJl9n8uldv2o0Ne4lCVO6+qLJFkM=; b=IUiVCxFfd72mgvDR/0vZwSVDZM2jMepIwsQuN/Nfg+2SAB1Y0fndIscd/E6Uk3NH7m vEEV03No4/NuLmN/jCT406AaAm68+zBMLtbfwhNuD63s26LIx1WE0Sx5k3h05tr6KfLq //TAfOlSezraK76uJFONfiupUZA4k6rkEUFdffHnON6mz8wpJ6RlCWTS9DthgTneMQVQ LIH/lsC/ekj3cGjYVNYWXYXYHqOwSWqBfpSko+wKUB330hOwLbCvh44tyOIxye9eqrPs EbofxOWwrJvhXMO0EbD6KvPGT0ZysUdcvvN4hHs+/JdPdWlYPuDtv/kLoGr7ml/n3Plf izFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=S9Qgko4eEaYlY03jJl9n8uldv2o0Ne4lCVO6+qLJFkM=; b=MnFXR/3q3/kBWd1ePFHHmnp8QfU+LESKu/9RQ6C7ro3bLj5ncKvxZcWlP+rjWiHkV1 v4aLfyjBqp5ooOBbSxB5cNLmBz1J8n9MHeCPUz+8tYfbgwEfY7vvDBktTYNMKQCnjRU0 Sai9Im5THOSbvfbrgLaoHyUbD/fT1Fs5Fo3DetUFudJEW5xB+pWFcgASb2TIs7KmeVZP mq8DYrb0c81uz9Qn8L2B1Wp3AECKi5HwqIdoH0gj8mFXUa01Q/K3BmecQeTBeuwoD3Jr 4IQs+cqTwjYZ1iBmfMR67S31r8GWuJla05lyJCpMJvIZGjPpPPnE4swYGQpeC3eReO1s 1j1A==
X-Gm-Message-State: APf1xPBeTIp/zLLI+9LEbc9T7tUzmeRvw8TZ7FAm/k08Jr7H2uM36sdM JQnfbBkd2TxrNIAzx8enk9pud31aXPzdFJrVvFI=
X-Google-Smtp-Source: AH8x224GEgjNIDvWyWqobLBXIYanmfE822/bFHHQEhVa80F5YuRsNzYEnHlNafVSCDAUpHztYKcQgoIFL/Tym8Z5II8=
X-Received: by with SMTP id r24mr14682405otg.338.1519860359040; Wed, 28 Feb 2018 15:25:59 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 28 Feb 2018 15:25:58 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Phillip Hallam-Baker <>
Date: Wed, 28 Feb 2018 18:25:58 -0500
X-Google-Sender-Auth: jWtsNEo-22sO2ELc8rpy5Voyxn0
Message-ID: <>
To: Eric Rescorla <>
Cc: Dave Cridland <>,
Content-Type: multipart/alternative; boundary="f4030437961ccf15bd05664e1006"
Archived-At: <>
Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Messaging Layer Security <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Feb 2018 23:26:01 -0000


Well maybe. It depends on how much of the complexity of the proposed
protocol is coming from the attempt to achieve 'PFS' and also what the
protocol is in fact achieving.

In general, I like to see what the requirements are before jumping to

Right now we seem to have a different key agreement approach for every
protocol. And we seem to be still doing key agreement the way we used to do
it in RSA even though we now use ECDH.


On Wed, Feb 28, 2018 at 6:18 PM, Eric Rescorla <> wrote:

> Hi Dave,
> I certainly agree with you that there are use cases where applications
> might want to archive communications.
> Generally, I think the right answer to these, however, isn't to modify the
> messaging protocol but rather to add that functionality on the messaging
> app over the top. That also is a much easier way to do new device history
> sync
> -Ekr
> On Wed, Feb 28, 2018 at 9:14 AM, Dave Cridland <> wrote:
>> 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
>> messages:
>> * 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.
>> Dave.
>> _______________________________________________
>> MLS mailing list
> _______________________________________________
> MLS mailing list