Re: [MLS] Use Cases for avoiding Forward Secrecy
Jon Millican <jmillican@fb.com> Wed, 28 February 2018 23:58 UTC
Return-Path: <prvs=65975d6d8e=jmillican@fb.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 36F22127058
for <mls@ietfa.amsl.com>; Wed, 28 Feb 2018 15:58:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.731
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key)
header.d=fb.com header.b=BqSPnBW6;
dkim=pass (1024-bit key)
header.d=fb.onmicrosoft.com header.b=S+QqLCsT
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 vCZZoNeJri66 for <mls@ietfa.amsl.com>;
Wed, 28 Feb 2018 15:58:07 -0800 (PST)
Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com
[67.231.145.42])
(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 CFF7F1241F3
for <mls@ietf.org>; Wed, 28 Feb 2018 15:58:07 -0800 (PST)
Received: from pps.filterd (m0109333.ppops.net [127.0.0.1])
by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id
w1SNt77p014783; Wed, 28 Feb 2018 15:58:06 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com;
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 mail.thefacebook.com ([199.201.64.23])
by mx0a-00082601.pphosted.com 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 NAM01-BN3-obe.outbound.protection.outlook.com (192.168.54.28)
by o365-in.thefacebook.com (192.168.16.16) 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; d=fb.onmicrosoft.com;
s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
bh=flXlSiTj88FUyQu6x6qrM3mnXxtCfacDr9FGWZixZks=;
b=S+QqLCsT3doUa7Ha7RO6U9kgFF1eJhKYeAV9pD/lurypv3FVy08G9seIg5pNUE3vDuyYZ9k43pFm3I8LCgRKvWbvmueVRBf+vwm9M0AQsUHg9BgRwO+otBxtzkk1ekSCYQBw5dKHiJew6JUvpjG5uuTONTdTqnlJBxVuIfhDL4U=
Received: from CY4PR15MB1751.namprd15.prod.outlook.com (10.174.53.141) by
CY4PR15MB1463.namprd15.prod.outlook.com (10.172.161.20) 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 CY4PR15MB1751.namprd15.prod.outlook.com
([fe80::3028:3f8c:6eeb:3256]) by CY4PR15MB1751.namprd15.prod.outlook.com
([fe80::3028:3f8c:6eeb:3256%17]) with mapi id 15.20.0527.021; Wed, 28 Feb
2018 23:58:02 +0000
From: Jon Millican <jmillican@fb.com>
To: Eric Rescorla <ekr@rtfm.com>, Dave Cridland <dave@cridland.net>
CC: "mls@ietf.org" <mls@ietf.org>
Thread-Topic: [MLS] Use Cases for avoiding Forward Secrecy
Thread-Index: AQHTsLeowtsdDTBzZk+HHlXOjx9LuqO6c26AgAALEIA=
Date: Wed, 28 Feb 2018 23:58:02 +0000
Message-ID: <B2A5860D-0154-4E43-86D3-46F0FAC2F75C@fb.com>
References: <CAKHUCzxOwmPrpUUj6HSRMcxiXtRmT05OapeBQdRA49bSWum6yQ@mail.gmail.com>
<CABcZeBPBqNUqhwzjFKdwv3TbW4U23zY-1um8Rz1mf4vFNJX=HA@mail.gmail.com>
In-Reply-To: <CABcZeBPBqNUqhwzjFKdwv3TbW4U23zY-1um8Rz1mf4vFNJX=HA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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: <CY4PR15MB1463D4AEA3BDD2383812E0F6DAC70@CY4PR15MB1463.namprd15.prod.outlook.com>
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;
H:CY4PR15MB1751.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;
A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: fb.com 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-OriginatorOrg: fb.com
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: <https://mailarchive.ietf.org/arch/msg/mls/RKMiKdgcvPRE2-cIe4l7KQk4XcI>
Subject: Re: [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 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" <mls-bounces@ietf.org<mailto:mls-bounces@ietf.org> on behalf of ekr@rtfm.com<mailto:ekr@rtfm.com>> 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 <dave@cridland.net<mailto:dave@cridland.net>> 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@ietf.org<mailto:MLS@ietf.org> https://www.ietf.org/mailman/listinfo/mls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=qL8XwY4DK13If0zpbmt6pcSE3iEl5EbKT0FY7L_a_-Q&s=0RrXaJNm0QXmkrg5W9sRhP6fd6iwfiK3Hpq7EPpfmjs&e=>
- [MLS] Use Cases for avoiding Forward Secrecy Dave Cridland
- Re: [MLS] Use Cases for avoiding Forward Secrecy Raphael Robert
- Re: [MLS] Use Cases for avoiding Forward Secrecy Phillip Hallam-Baker
- Re: [MLS] Use Cases for avoiding Forward Secrecy Stephen Farrell
- Re: [MLS] Use Cases for avoiding Forward Secrecy Phillip Hallam-Baker
- Re: [MLS] Use Cases for avoiding Forward Secrecy Dennis Jackson
- Re: [MLS] Use Cases for avoiding Forward Secrecy Phillip Hallam-Baker
- Re: [MLS] Use Cases for avoiding Forward Secrecy Dave Cridland
- Re: [MLS] Use Cases for avoiding Forward Secrecy Phillip Hallam-Baker
- Re: [MLS] Use Cases for avoiding Forward Secrecy Eric Rescorla
- Re: [MLS] Use Cases for avoiding Forward Secrecy Phillip Hallam-Baker
- Re: [MLS] Use Cases for avoiding Forward Secrecy Dennis Jackson
- Re: [MLS] Use Cases for avoiding Forward Secrecy Jon Millican
- Re: [MLS] Use Cases for avoiding Forward Secrecy Stephen Farrell
- Re: [MLS] Use Cases for avoiding Forward Secrecy Phillip Hallam-Baker
- Re: [MLS] Use Cases for avoiding Forward Secrecy Richard Barnes
- Re: [MLS] Use Cases for avoiding Forward Secrecy Dave Cridland
- Re: [MLS] Use Cases for avoiding Forward Secrecy Dave Cridland
- Re: [MLS] Use Cases for avoiding Forward Secrecy Russ Housley
- Re: [MLS] Use Cases for avoiding Forward Secrecy Phillip Hallam-Baker
- Re: [MLS] Use Cases for avoiding Forward Secrecy Jon Millican
- Re: [MLS] Use Cases for avoiding Forward Secrecy Sean Turner
- Re: [MLS] Use Cases for avoiding Forward Secrecy Dave Cridland
- Re: [MLS] Use Cases for avoiding Forward Secrecy Dave Cridland
- Re: [MLS] Use Cases for avoiding Forward Secrecy Katriel Cohn-Gordon
- Re: [MLS] Use Cases for avoiding Forward Secrecy Dave Cridland
- Re: [MLS] Use Cases for avoiding Forward Secrecy Eric Rescorla
- Re: [MLS] Use Cases for avoiding Forward Secrecy Nadim Kobeissi
- Re: [MLS] Use Cases for avoiding Forward Secrecy Dave Cridland
- Re: [MLS] Use Cases for avoiding Forward Secrecy Stephen Farrell
- Re: [MLS] Use Cases for avoiding Forward Secrecy Dave Cridland
- Re: [MLS] Use Cases for avoiding Forward Secrecy Nadim Kobeissi
- Re: [MLS] Use Cases for avoiding Forward Secrecy Phillip Hallam-Baker