Re: [MLS] Use Cases for avoiding Forward Secrecy

Dave Cridland <> Fri, 02 March 2018 20:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E281412D7F1 for <>; Fri, 2 Mar 2018 12:27:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zHTVA63eg24J for <>; Fri, 2 Mar 2018 12:27:06 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 50E6F126C25 for <>; Fri, 2 Mar 2018 12:27:06 -0800 (PST)
Received: by with SMTP id 70so15068543lfw.2 for <>; Fri, 02 Mar 2018 12:27:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=p6Rdh+Lig5zLeiE6c4a80pCVCOjCdplVEOzQA5mIQ9U=; b=IFkCdyDa+IAw16w/rQ49JL02Imi2kAUKf2NXU3lgL2hlHXLpZqZnXekyQZhxMoXawi SNpjC5q0gUu1DJZNNdduxpaK5e47Sw/xhtN7cImNIiynllBkEH/JzZnhPY9MB+V4r3gi Aw1ivtCcoYzHy5G/84ue+VwqJwlrtYaLNPmUI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=p6Rdh+Lig5zLeiE6c4a80pCVCOjCdplVEOzQA5mIQ9U=; b=CHcAWylYCBt93IzoSX7gU0cZ901rGz6r6v9fUAbgsHNWotcHHwyWqWA80PYQZoG9z9 LPzWnTaTU9x7moNNkLLP0Wx+JkG9gUb62EApnWD0A7xkcvGvXjCq8cC23L8UieZZxR8/ PiDIorv+fHcOIZEVZkWs6adNAtm7fgq/VyU8tii39V8QQFKYuMB1hn5IWVD8alTKEeZI 9zwaBpMvVp9jFOqGTOHjBQM7bJ9v3KmTwxu5jG6zZbNzUiwnLe0hC78xtNeZ2FhNpeWb nfOrYnYcxx7nYOKJbywfh3VLJ0Fbr8AQad2tY8JK/Kj+M4I+vx/7zr3LLuBvTjOCkgRY 5D3w==
X-Gm-Message-State: AElRT7GwWsu6D3z9DoaLKUz0BiGAhNc7yxaKW5mCA8jSkcEsfRwt4uPP 7Io++HaxzJwJdJfu6LryNGpRFnAMRDsGNb+3P2jav0YJ
X-Google-Smtp-Source: AG47ELsiUsVzN3vxtHcnt666cjCDdSM6fNbsRopHz8FLdEA7h3Rk/qTtDMb8v8DK5dfE/HV5rlij104XA2ul7OVKX4A=
X-Received: by with SMTP id a124mr4299557lfa.35.1520022423189; Fri, 02 Mar 2018 12:27:03 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 2 Mar 2018 12:27:02 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Dave Cridland <>
Date: Fri, 2 Mar 2018 20:27:02 +0000
Message-ID: <>
To: Nadim Kobeissi <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Fri, 02 Mar 2018 20:27:08 -0000

On 2 March 2018 at 18:14, Nadim Kobeissi <> wrote:
> A3. With regards to retention, I think EKR makes the best point in saying that these are use cases best addressed by features implemented by the client application itself. This rhymes with Dave Cridland's original mention that business users are those who most require this: business users are also those with the most tailored client applications, usually, providing ample room for archiving features that do not necessarily affect protocol security goals or expose MLS to a riskier threat model.

After various side-discussions, I'm comfortable that we can address
the demands of enterprise and government cases within MLS - as long as
we keep a half-eye on it.

> A4. With regards to compliance with, for example, MIKEY-SAKKE, it is worth thinking about whether the entire MLS effort remains as worthwhile were it boiled down to that common denominator. MIKEY-SAKKE (and company) are by design allergic to strong security guarantees. Phillip Hallam-Baker is correct to note that strong security guarantees are not our explicit goal here, but rather a tangential goal to securing MLS use cases to the fullest possible extent. That said, as noted by Jon Millican, any run-of-the-mill secure messaging application today, be it WhatsApp, Signal, iMessage, Facebook Messenger, Google Allo, Viber, Wire, or Threema shows an obvious preference for ephemerality and resistance to scenarios where the mobile phone, an increasingly disposable device, gets lost, stolen or traded away.

To be absolutely clear, I'm not a big fan of SAKKE and I think it's
entirely unsuitable for the consumer in any form. Consumers generally
benefit from FS, and SAKKE's mandatory escrow is just plain wrong in
that setting.

The properties that interest me within MIKEY-SAKKE are the possibility
of a secure archive with offline escrow, and I think we can do that
within MLS after discussion.

I actually think this is a fairly well-understood requirement, and as
such it'd be useful to document it somewhere in the charter.