Re: [MLS] Use Cases for avoiding Forward Secrecy

Jon Millican <> Wed, 28 February 2018 23:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36F22127058 for <>; Wed, 28 Feb 2018 15:58:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.731
X-Spam-Status: No, score=-0.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=BqSPnBW6; dkim=pass (1024-bit key) header.b=S+QqLCsT
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vCZZoNeJri66 for <>; Wed, 28 Feb 2018 15:58:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CFF7F1241F3 for <>; Wed, 28 Feb 2018 15:58:07 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id w1SNt77p014783; Wed, 28 Feb 2018 15:58:06 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=flXlSiTj88FUyQu6x6qrM3mnXxtCfacDr9FGWZixZks=; b=BqSPnBW6YKiZUbDOFYq0TW6auiC2QqV89RKnIJFKPh6LnJXeA8stcZBlV7XJsk5rdfZO YRkJxvj76I4p4MQEopCHArr87XG6MzKaeHtmhH5aSOGN4Sb/OJUnzxPJvLKOtD0M/FMO yhT2j0FYTp3s50mpwDy/5S5fTj74Ur+H6AE=
Received: from ([]) by with ESMTP id 2ge6g581jt-2 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Feb 2018 15:58:06 -0800
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 28 Feb 2018 15:58:05 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=flXlSiTj88FUyQu6x6qrM3mnXxtCfacDr9FGWZixZks=; b=S+QqLCsT3doUa7Ha7RO6U9kgFF1eJhKYeAV9pD/lurypv3FVy08G9seIg5pNUE3vDuyYZ9k43pFm3I8LCgRKvWbvmueVRBf+vwm9M0AQsUHg9BgRwO+otBxtzkk1ekSCYQBw5dKHiJew6JUvpjG5uuTONTdTqnlJBxVuIfhDL4U=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Wed, 28 Feb 2018 23:58:02 +0000
Received: from ([fe80::3028:3f8c:6eeb:3256]) by ([fe80::3028:3f8c:6eeb:3256%17]) with mapi id 15.20.0527.021; Wed, 28 Feb 2018 23:58:02 +0000
From: Jon Millican <>
To: Eric Rescorla <>, Dave Cridland <>
CC: "" <>
Thread-Topic: [MLS] Use Cases for avoiding Forward Secrecy
Thread-Index: AQHTsLeowtsdDTBzZk+HHlXOjx9LuqO6c26AgAALEIA=
Date: Wed, 28 Feb 2018 23:58:02 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2620:10d:c092:180::1:9340]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR15MB1463; 7:VjGRwb4HNF73KqBPyWwisQ51vyxMQI+2BPM07IN4h/zs56nzvY5/klkeMaj9L3bFZWffxzdzdrUCzQQsjYSB3yKhjEGd/0JkTju1K0h+YZHRH+iw/RhzyTZowko43TKm5V+Lb4SvbT9xG1ijp7KxctuOEwPkauhtUC68tn9I7O2Z8e+D6WixIHZFNZcLwrvDkqNDHzTNASlXPxul56jbX/Wy7TN6fC9h81T7O//QiY7SJpfzlVxa7X9Xv/tsNO/E; 20:K/D5n7vF0OxaEfrdbCub8N0jsX386BhEo+zJV5Otj6Zm+VaRyNNSZ/FMFw6vnd4gv8rE9KkLxG8PRCAX/tvAJO05SmXbQgGilsYcIibigrRk+97Z+OEMqp8C7kUXt9iayV6oclkyExW01LhLVQnZNceS3ic7qmt05UY8pe13WB8=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: d64ce2f5-ac94-419a-fb56-08d57f071a7c
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CY4PR15MB1463;
x-ms-traffictypediagnostic: CY4PR15MB1463:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(278428928389397)(209352067349851)(192374486261705)(21748063052155)(10436049006162);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231220)(11241501184)(944501221)(93006095)(93001095)(6041288)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR15MB1463; BCL:0; PCL:0; RULEID:; SRVR:CY4PR15MB1463;
x-forefront-prvs: 0597911EE1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(39860400002)(396003)(376002)(366004)(199004)(189003)(4326008)(2950100002)(102836004)(229853002)(36756003)(33656002)(7736002)(186003)(53546011)(6506007)(5250100002)(2900100001)(606006)(68736007)(478600001)(966005)(6486002)(6116002)(83716003)(6436002)(6306002)(14454004)(3660700001)(6246003)(54896002)(25786009)(8676002)(86362001)(6512007)(81156014)(236005)(81166006)(53936002)(59450400001)(3280700002)(97736004)(561944003)(5660300001)(110136005)(76176011)(105586002)(316002)(8936002)(106356001)(2906002)(82746002)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1463;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: tVPCh7SbUO7wk/RFXMhn+w8tmCTcPnL3tz3GVWmB1Xj6i4BA1AIQoQNUWyNgrVal9K3Yi177iVylLQO/G3Ug8lNkB6oG/csnFBj8BBzRGP0i6+2uSg+rDNUvRDeYvqFSn6pbvrRHuHwxvL/DdqECcPrAwYQm4KteSK4rZK/oHns=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_B2A5860D01544E4386D346F0FAC2F75Cfbcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d64ce2f5-ac94-419a-fb56-08d57f071a7c
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2018 23:58:02.7752 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1463
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-28_12:, , signatures=0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
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:58:10 -0000

One benefit to the ratcheting approach in the proposal is the immediate lock-out you get when a participant is evicted from a group. This is a different property from forward secrecy; but if we do wish to have this benefit in the protocol then I believe that we will have to be tolerant to mutations of message keys, and that any mechanism to retrieve message history or escrow messages would therefore have to tolerate messages being encrypted with arbitrarily many keys. If you can support this for eviction-triggered key mutations, I feel like it wouldn’t be much of a stretch to make it work on top of a forward secret protocol.

Of course, one possible set of requirements could tolerate evicted group members retaining access to the group encryption keys – which would render my above point moot – but this would feel to me like quite a strange security property to have.

On 28/02/2018, 23:19, "MLS on behalf of Eric Rescorla" <<> on behalf of<>> 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


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

* 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.


MLS mailing list<><>