Re: [MLS] Use Cases for avoiding Forward Secrecy

Jon Millican <> Thu, 01 March 2018 17:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC9CE12EB70 for <>; Thu, 1 Mar 2018 09:00:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Status: No, score=-2.719 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=Zmy2vrit; dkim=pass (1024-bit key) header.b=CIn5vjRe
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9p7uarqwZ4pv for <>; Thu, 1 Mar 2018 09:00:18 -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 BAEA212EB68 for <>; Thu, 1 Mar 2018 09:00:03 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id w21GsOrb025233; Thu, 1 Mar 2018 09:00:00 -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=7d6WaH31GmlhK/AjVSDYwN2h4SRz86b/vAQmV6+nAbQ=; b=Zmy2vritahS/K+KkGg1B+2PXNEHlIXKAErVTb935BJkGoADOhybXX5WKWqbL6FY1cotZ E3kGZEsITsI/33ueg+mDLnCQ+YKvLlDchJ820SyRSwf9tw3Z7sgWo3QgzA3zYGjFXyWN /0lKIs5xw8LPKafqgDx4xGMGLpSW1F65br8=
Received: from ([]) by with ESMTP id 2gecqb98jy-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 01 Mar 2018 09:00:00 -0800
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 1 Mar 2018 11:59:59 -0500
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=7d6WaH31GmlhK/AjVSDYwN2h4SRz86b/vAQmV6+nAbQ=; b=CIn5vjReicguqBdx+X+ouhw/7I7+K+lW1vydQFbybUgAFwQfM4mLCl8vSG5B9tv1nohyP3BY2PxhKKoa98y0v0rPPnIx1HNrNRnrUnxc4krZgiD1h64u1BL11wJ41hcGlX1IQtjnUIKDWBTbyVdogmRuRGItUlUeQuHtkqpQ2Qk=
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; Thu, 1 Mar 2018 16:59:58 +0000
Received: from ([fe80::3028:3f8c:6eeb:3256]) by ([fe80::3028:3f8c:6eeb:3256%17]) with mapi id 15.20.0527.021; Thu, 1 Mar 2018 16:59:58 +0000
From: Jon Millican <>
To: Phillip Hallam-Baker <>, Russ Housley <>
CC: "" <>
Thread-Topic: [MLS] Use Cases for avoiding Forward Secrecy
Thread-Index: AQHTsLeowtsdDTBzZk+HHlXOjx9LuqO6c26AgAEKQYCAABc6gIAABxoA
Date: Thu, 1 Mar 2018 16:59:57 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2620:10d:c092:180::1:8f46]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR15MB1735; 7:sukX+/RfrqsPg4Zud+3Ds3ShGcSHE3QNfYTjqqT9UMX0TU+6TxWlxmSXhGlgTtGUELJ7NMZJyJIw/OxpqSuFCRNLhUWgwSP4P78KvGyo+ZXY2VbaEibFf5V2A+DzrB/F7LnV4D33z1PAd0vdNBzSgDZJnPWUhcgjCdBuNu77fnq2gGavSfscVnlByEwrbqFSFdz/0wJzwJeHTDPbVlXKult5zXaXL7A/3303RQKQNs+qJd3gwf1q6dL0LlbxXHd4; 20:Zzk5dHOp1WqLJiEaCHbkio/lM6WWEdNRALWflGjkVKLaESI6Fw7CDdQDgOR1Se4KX6NczwKukRRqZkAyj/FkDsRwRuRidNbxauWZ5RiE29Tep7wkKuKKVDdCvjnpMDPWM6xa5DBaC6B2mve0Qro62hmlWiYqao2jMQOAfK9EQdU=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: f3acf6b1-6043-4e0a-ae86-08d57f95dd2b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CY4PR15MB1735;
x-ms-traffictypediagnostic: CY4PR15MB1735:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(28532068793085)(278428928389397)(192374486261705)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(3002001)(3231220)(11241501184)(944501224)(93006095)(93001095)(10201501046)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:CY4PR15MB1735; BCL:0; PCL:0; RULEID:; SRVR:CY4PR15MB1735;
x-forefront-prvs: 05986C03E0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(366004)(346002)(396003)(376002)(199004)(189003)(102836004)(97736004)(82746002)(110136005)(99286004)(561944003)(93886005)(236005)(6486002)(25786009)(4326008)(6512007)(54896002)(6306002)(316002)(186003)(3280700002)(6116002)(6506007)(53546011)(5250100002)(2906002)(105586002)(14454004)(478600001)(76176011)(59450400001)(2900100001)(68736007)(8936002)(5660300001)(83716003)(7736002)(53936002)(81156014)(6246003)(8676002)(3660700001)(81166006)(33656002)(229853002)(2950100002)(6436002)(86362001)(36756003)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1735;; 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: fVdfJTrt2ZczHrbpIHc75es2slgLH9GycOhnQJtWJY61d6+mz6venmL7L3DthI6B6fA0KyU+bC6VtKSZOYkduQY0WrY2BmbV8/u5ZQjZj3rHzvAaH/5Ar2B5lgS5WbcCres/VUb8WKHH3nSL3dhTmywy9x1R59WexthZUjv6L4w=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_6337AD1BD1A84D3F8890A36ED46B47D9fbcom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f3acf6b1-6043-4e0a-ae86-08d57f95dd2b
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2018 16:59:57.8712 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1735
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-01_09:, , 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: Thu, 01 Mar 2018 17:00:21 -0000

If the question is about whether MLS should support forward secrecy in the first place, I think consumer E2E messaging applications provide a good use case for this. The threat model that we tend to take here is that the user has limited trust in the service provider. In this situation, the security properties provided by TLS are almost moot, as TLS only protects you as far as the service provider anyway.

Ephemerality is a very common property in such apps, with the explicit goal that messages not be accessible after a certain period. Even without ephemerality, I believe that most messaging support message deletion. In such situations, forward secrecy is very desirable, as it ensures that if keys or any device state do leak at any moment (be it from an exploit, somebody imaging a device, or a temporary bug in the app itself), users’ old messages can at least remain secret, even if the provider had retained all of their ciphertexts. This also leads to a similar case for Post-Compromise Security, in that secrecy can be recovered even after any sort of key leakage: although in this case the argument applies even when no messages are ever deleted.

On 01/03/2018, 16:35, "MLS on behalf of Phillip Hallam-Baker" <<> on behalf of<>> wrote:

On Thu, Mar 1, 2018 at 10:11 AM, Russ Housley <<>> wrote:

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

This is similar to the approach used in some email environments.  The email message is decrypted for reading, and then encrypted in a separate archive key for storage.


​It is a valid approach and it might be the right approach.
​But what we have right now is a rather complex proposal that may or may not be correct and may or may not be addressing the real requirements and may or may not be addressing them in the most straightforward fashion.

So far I have seen a lot of defensive responses and one individual whose behavior was bullying. Now the fact that I cannot be bullied out of my opinions does not make ​the experience of people making personal attacks any more pleasant for me.

More importantly, I am concerned that what has been more or less explicitly stated is 'we have our proposal and if you don't like it then bog off'.

I don't think that language encourages honest debate about the limitations of the proposal or identifying the flaws.

I would much rather the IETF endorse no proposal than one that only navigates the process because a group of bullies shouted down anyone who was critical of it. We saw that happen with DANE we saw it happen with CBOR. CBOR does work but the consequence of shutting down the voices saying that we needed a binary format that precisely matches the semantics of JSON is that we had to spin up a separate COSE working group to repeat the work of JOSE rather than simply apply the encoding.

The assumption of most here is that the requirements are easy and the cryptography is hard. That is precisely the wrong way round. If we really understand what the requirements are, the cryptography follows almost directly. It is getting to the understanding of the requirements that is the hard part.