Re: [MLS] Use Cases for avoiding Forward Secrecy

Stephen Farrell <> Thu, 01 March 2018 00:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E0DE126C2F for <>; Wed, 28 Feb 2018 16:07:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 E8xhIFH1zL9B for <>; Wed, 28 Feb 2018 16:07:06 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB96412426E for <>; Wed, 28 Feb 2018 16:07:05 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F147BE50; Thu, 1 Mar 2018 00:07:02 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cAm_ghILBEwi; Thu, 1 Mar 2018 00:07:00 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 49357BE4D; Thu, 1 Mar 2018 00:07:00 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1519862820; bh=cTl0MV2sP4wVGyW7+TJ0gf75fDQGkyrrKUzV8v3XQHU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=3GVjfRi31JlgIvNWiVJ76mbw+wHoJ7/LQDwgI1K/pm+dQ/bfaVMLw4nBUmRvg+KCq CayEpJgRBQjs/nd9zRJykXCdVrg4CUdLz4MYkaHbdAnnG34M32B2agMuykKq0i00MR EywR9SsdI7cc66T0qjesXDi8hNzG1xXcOeL6dNbk=
To: Dave Cridland <>
References: <> <> <>
From: Stephen Farrell <>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Message-ID: <>
Date: Thu, 1 Mar 2018 00:06:58 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="47BAlBFzSJIL6QzgUdQDZzqz1bPxoAT5F"
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 00:07:08 -0000


On 28/02/18 22:56, Dave Cridland wrote:
> On 28 February 2018 at 21:16, Stephen Farrell <> wrote:
>> Hiya,
>> On 28/02/18 17:14, Dave Cridland wrote:
>>> 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.
>> Sorry, why is transport layer security not sufficient between you
>> and your tax authority?
> Because it's not a single hop.
> Supposing my tax authority uses XMPP, for example, and so has (in my
> case) as an XMPP domain. I use some commercialish XMPP
> provider. I don't want my provider to be able to read my tax messages,
> nor do I want them archived in plaintext on the server (although I
> probably do want a verifiable record). Meanwhile, HMRC wants to keep
> an archived, but secured, copy at their end, viewable by their
> organisation.

I see no evidence that would ever prefer to handle
tax information via any intermediary when they have the option
to provide a URL to a tax payer or their agent. But perhaps you
do have a convincing use-case along those lines. If so, then I'd
say describing that, rather than asking to back off from forward
secrecy, might be a better approach at this stage (even if your
concern is really with the FS aspects of current MLS proposals).

>> I'm unclear as to why the security guarantees (aimed for) between
>> groups of people ought be reduced in order to meet the goals of
>> securing communications between a person and a service provider.
> I'm not suggesting they should be.

FWIW, that's how I read your message. Apologies if I misread it.

> I am suggesting that it might be nice if my options were not simply FS or FO.


> (Besides which, the archives in a non-FS situation gain some security
> guarantees, too).

Again, specifics there would be useful. I can't evaluate the
sentence above.

>> I do agree that it'd be good if a user of some application could
>> add a new device and still see old messages, but I'm not at all
>> clear that's that significant (for the crypto) since people will
>> always need to have some kind of fallback to handle cases where
>> they've lost state.
> Assume a FS-only message transfer. In that case, how do we recover
> missing messages? 

I've no idea. But MLS isn't aiming to provide interoperable messaging
(sadly but understandably IMO), so that seem a tad out of scope, as
ekr pointed out.

> We have to transport those from another device that
> has them. That's a perfectly reasonable concept, and one that has been
> tried before in Skype. Unfortunately, as mobile devices replaced
> desktop/laptop combinations as the dominant device, they switched away
> from the design back to centrally-held archives since the clever
> synchronisation options simply didn't work.

I'm fine if MLS is only usable by some subset of interpersonal
messaging applications myself, even if the precise delineation of
the set of applications that can use MLS isn't precisely known.
(So long as there are a useful set of applications that can use

> Of course, there are users who prefer the trade-off of higher security
> and no (or limited) archives. Such users would, one hopes, be warned
> about the change in security should they enter into a conversation
> with someone who cannot (or will not) support FS.

I don't think such subtle differences are at all desirable myself.


> Dave.