Re: [MLS] Use Cases for avoiding Forward Secrecy

Nadim Kobeissi <> Fri, 02 March 2018 18:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B368B12D871 for <>; Fri, 2 Mar 2018 10:15:02 -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 (2048-bit key) header.b=J+1OumYl; dkim=pass (2048-bit key) header.b=RfCaRm3M
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qrFlJpf9fKU3 for <>; Fri, 2 Mar 2018 10:15:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AB12812D7F2 for <>; Fri, 2 Mar 2018 10:15:00 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 063FE20B4D for <>; Fri, 2 Mar 2018 13:15:00 -0500 (EST)
Received: from web1 ([]) by compute1.internal (MEProxy); Fri, 02 Mar 2018 13:15:00 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=bErrBW+x3b/UkUcZs DpeZNo8PuLbTAHfZ6fkSsjqu2w=; b=J+1OumYldZx0JVA7GJ23aka0UKqNBk/9R i0Lc0OkY48mD56xIulxNh2A3K+LFUqiODjNnZG8HRuQPZ0z3AdfNJrxiLi9o8Lm0 axko4pjw99FGOogXCjF3yRT7yVZ7+hYVzqIgf7+upchWuOQ9Y6v3B04jUYMbQ669 TZJ90dXd7PtLCtGJOrkwFTJZlWzyFjQSW6Fp0nTDTCSpXT/y9l6BmcDDKuDoc2o8 ETrP6jmRTRqAdZ2YQr0EDytWSFBqk3kdP9KgIWk80DmlZmHWV2kBl2Is2hKYoNGg ++AyLO46yWyw2qKB5nXaf6iNj4Yrx5CLQXUgyr6+URg7Em0fB9ouQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=bErrBW +x3b/UkUcZsDpeZNo8PuLbTAHfZ6fkSsjqu2w=; b=RfCaRm3MdW65MdX/oJbTWV p7uUIOlLCyFP03ISycnGoucuK0lm7rXTrsVrCQTocCb1wfumUmMRsKCopT1nGzR2 lIfFqLu4X8k8cJwO3uaSl2q1YH8wCD6i21cuX60AdN8ww5iFNHwt3Hf+4YSUxyjx MQ/NXVlI4+gWbmr8Og8b9u3ptXOY0xCsFlTVSNKpTZJWtLQCfdYn5EbFcQjYAuOu 9KWYHm8UY+R/NCdkMSEn7jXNCcazhxMehGDCx+2mfnVRDIx7Z/IN/F8ZObvM2pOi InpEiGet7KN56Fjsa3xGxp8xbotsIY/wk7F9TrihUuo4Hz32RoO37Sdg7G5SsUsg ==
X-ME-Sender: <xms:o5SZWsBVvRTYC_5BXq8X-kW_tz21Ybi6bbXWKD91iLdaK-jqtFfYJQ>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id C5AAB9426A; Fri, 2 Mar 2018 13:14:59 -0500 (EST)
Message-Id: <>
From: Nadim Kobeissi <>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Mailer: Webmail Interface - ajax-b08ff009
In-Reply-To: <>
References: <> <> <> <> <>
Date: Fri, 02 Mar 2018 19:14:59 +0100
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 18:15:03 -0000

There is a small body of contributions I have regarding this discussion thus far. They are organized below in a set of more general comments, followed by specific responses to Phillip Hallam-Baker.

A1. Moving forward, it's likely just better for us to refer to forward secrecy as forward secrecy. The "perfect" suffix, historically, largely exists for anecdotal reasons and has little to do with the actual concrete meaning to the term in reference to its security goals. "Forward secrecy" and "future secrecy" are confusing terms anyway: for one thing, they seem to refer to the same property, although they are diametrically opposed with regards to the chronological direction in which confidentiality and key freshness hold, post-compromise.

A2. As alluded to by Denis Jackson, asynchronous forward secrecy is documented by the Signal protocol. As far as I know, the earliest existing design that does this asynchronously is NAXOS [0], which I believe was cited in earlier drafts of the Signal protocol specification anyway.

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.

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.

A5. As someone who's been involved in secure messaging for some  time, I can say that it's by no coincidence that Signal was designed to focus so strongly on both forward and future secrecy. The designers clearly went to great length to keep these properties, and, in implementation, modulate their resilience against an unreliable (choppy, weak) network by keeping a certain number of pre-key hash chains locally. The more hash chains are kept, the more out-of-order messages are tolerated by the wider the post-compromise window. To my knowledge, WhatsApp keeps a larger local set of hash chains than, say, Signal or Cryptocat, in order to account for its larger user base who may have a smaller tolerance for failure. As a matter of fact, Signal as an application evolved away from using pure OTR into designing and using the Signal protocol largely in order to improve upon forward secrecy specifically, adopting an asynchronous forward-secure AKE and a ratcheting scheme that handles two-party key contributivity much more quickly than OTR.

A6. I think it's doubly more important to consider adopting EKR's suggestion, discussed in (A3), to its fullest possible extent because of the negative impact that accommodating against forward secrecy may have towards enabling downgrade attacks that chip away at forward secrecy. Once this is ingrained into the protocol, we may end up having to give an active attacker much stronger  grip over when, and even if, forward secrecy ever kicks in.

Some responses to specific claims made by Phillip Hallam-Baker:

PHB Statement 1: "Alice works in a team with Bob and Carol. At some point Doug joins the team. At that point, Doug needs access to all documents and discussions related to the project."

Response 1: Especially given that this seems to potentially require expanding the MLS problem space to document access, it is definitely best to follow EKR's recommendation, as mentioned above in (A3). Not only does this provide appropriate document access irrelevant of forward secrecy guarantees of MLS, but it also segregates key retention to involve only documents that merit such retention, and from a software engineering standpoint is likely the most elegant solution anyway.

PHB Statement 2: "If Alice creates a message for Bob using only her knowledge of Bob's public key then it is not going to be PFS because a compromise of Bob's private key is a breach."

Response 2:   The consequences of the secrecy of the very first message in a Signal session, given a long-term identity compromise, are not as you describe. That is because you would also need to compromise Bob's one-time pre-key, which is erased after the AKE concludes. The consequences of both these kinds of compromise are modeled and documented by Katriel's Signal paper, as well as a contemporary paper published by our team at INRIA.

PHB Statement 3: "In general, I like to see what the requirements are before jumping to implementation."

Response 3: It is quite likely that any current implementation of MLS isn't very fruitful. Better to discuss more first, especially at the upcoming meeting at IETF 101.

PHB Statement 4: "This is a different problem to TLS because we have more than two parties and it changes matters."

Response 4: The manifestation of the problem is what is different. Not the problem itself. The problem is layer security. TLS had to implement forward secrecy in order to have a meaningful answer to that problem. In messaging, the problem of layer security is the same, but manifests itself in a different medium. Forward secrecy is in all likelihood still necessary to offer those affected by this problem the level of security they require given a reasonable threat model.

PHB Statement 5: "One of the things I only just realized is that PFS is not even a property of the protocol, it is a property of a key in the exchange and not of the exchange itself."

Response 5: Either this statement is incorrect, or all peer-reviewed publications that exist on secure messaging must be rewritten in order to formalize, model and prove forward secrecy on the level of the lifetime of a symmetric key rather than as a global property encompassing all messages of a protocol. Of course, there are different methods in which to reason about the same thing: you can see a finite field as a weird squiggly line or as a set of numbers, etc.

PHB Statement 6: "Let us say that we want FS with respect to each of the keys of Alice, Bob, Carol and Doug but ​they don't all want to inject fresh FS information at the exact same time. Let us say Alice has her key in a HSM while Bob is using a soft key, Alice is sitting in a SOC and Bob is a field agent on Moscow Rules. Bob probably wants for FS their key every ten minutes. Alice might be good for a week."

Response 6: In a protocol such as, for example, Signal, such a discrepancy can be managed by the participants without affecting the protocol's implementation logic in any way, further supporting EKR's suggestion described in (A3) and touched upon previously in the response to PHB Statement 2.


Nadim Kobeissi
Symbolic Software •
Sent from office

On Fri, Mar 2, 2018, at 3:51 PM, Eric Rescorla wrote:
> On Fri, Mar 2, 2018 at 1:51 AM, Dave Cridland <> wrote:
> > On 1 March 2018 at 15:11, Russ Housley <> wrote:
> > > 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.
> >
> > Sure, but that explicitly means that messages within the archive can
> > no longer be authenticated, doesn't it?
> >
> Not if they are digitally signed, which is an explicit option in the
> current drafts.
> -Ekr
> That, in turn, is a clear downgrade from the NCSC's SAKKE dictat. For
> > all its faults, that is providing a secure archive that the enterprise
> > has access to via an offline key escrow.
> >
> > If I'm wrong here please don't hesitate to correct me.
> >
> > Dave.
> >
> > _______________________________________________
> > MLS mailing list
> >
> >
> >
> _______________________________________________
> MLS mailing list