Re: [MLS] Use Cases for avoiding Forward Secrecy

Phillip Hallam-Baker <> Sat, 03 March 2018 02:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C0FE312708C for <>; Fri, 2 Mar 2018 18:09:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yzlAle6SweOm for <>; Fri, 2 Mar 2018 18:09:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0B4A7127078 for <>; Fri, 2 Mar 2018 18:09:28 -0800 (PST)
Received: by with SMTP id b8so8404751oib.11 for <>; Fri, 02 Mar 2018 18:09:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RhhMnnEkP0TZOjpFJT/vBdpBInhWONVSDHrVWKJyq94=; b=M8YBXfkiSZbzIs4XOOKPW4b3LHKLzKf21rwi7N0FyZ59cjW+FGaXWg5fM7iOBYchYW WKjonMIZNZDa+pQ1Sgasj2l+QO1SU6uqA4rY/S1y4cUXqd93+jviaq4kt+N6kmluZB4q 5zQNJ7goYHKlC89wH4DYFBkVFTU3DmmcRL3BMQWiCttsElRwF9IrT11ibmWQs1iGWZ8L zCIOpHiuPwlkRmhakUR25pt6AlXJN6WZmewGXnIkXbczli0OXODmHs9uOeXqBT09Xs+T xNbBnA39OEVXuUaYCdDVqdBe1j31dPXsqXtPiqwNW5mGTqbeXHwtiB+e/ilNlE5Jr8lw J+1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=RhhMnnEkP0TZOjpFJT/vBdpBInhWONVSDHrVWKJyq94=; b=DmkPaCM8kOYEoe8STahVit6I5iaHEWoND+3XqV43x7yPl7ClSXa3WJd0C2/xHnaHwH fJ2oMgv2hCAA1PCOmYOR9c3uHLPd63QWQ2Y3RJSex1NQFCMPIq0CHO6IDrxW1loRRBDn CccUGfptIitbq8n0qL8D1aEfFhT/EOAPzsj1H4eFtjNMF6axe5mlV1YmJ0s6k1OeYH9V cCeFWLAuu7XLrnKXDTZs3lUOPF+w/Cbc6copCTpgxfeLQBRJEVcpiM/7co29uFzeocC8 ckvrW74Y6X9Cpg1qFvUnbIyiehnHZNP/xLmsytIdeTguBy25RsaBGQP7x+/eaoBlLA2b Gb7A==
X-Gm-Message-State: APf1xPC0bporSyNGeyrl+nPISaIHfGWUS9Ez7VpQga7EDR+NPu7RFgB1 r5M82mUn++YDwP+2MUAZNK+AnQj0BjUDpaN3SHpMWA==
X-Google-Smtp-Source: AG47ELtittLOHBJPys3iB1ow7wM8hCT1PLq4JET2A9HCeeOXPw/Y8p0QykkvR3zCeUearZWoQ2Mnn9lNxt2BYzwTfT8=
X-Received: by with SMTP id e68mr5182208oig.34.1520042967186; Fri, 02 Mar 2018 18:09:27 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 2 Mar 2018 18:09:26 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Phillip Hallam-Baker <>
Date: Fri, 2 Mar 2018 21:09:26 -0500
X-Google-Sender-Auth: riag38F1B82lj5SsXe9eSiOvvHk
Message-ID: <>
To: Nadim Kobeissi <>
Content-Type: multipart/alternative; boundary="001a113cdb041a42e605667895e0"
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: Sat, 03 Mar 2018 02:09:30 -0000

On Fri, Mar 2, 2018 at 1:14 PM, Nadim Kobeissi <>

> 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.
​My point is that discussions, i.e. the application for which we might want
to use MLS very often have precisely the same security requirements as
stored documents for which it is understood FS is not​ a requirement.

> 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 has just taken you outside the scope of my statement. This is
exactly the point I am making. I can add FS to a protocol really easily,
just mix in another one time key. ​When I say 'only her knowledge of Bob's
public key' that is what I mean, not 'only her knowledge of Bob's public
key plus this other stuff'.

​So the way to avoid FS in the case that it is undesirable is to not mix in
the key in the first place. That is, FS is a security enhancement of a non
FS-protocol, not something we design in and then take away.​

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.

​I agree on that. And I find that quite often it is necessary to build
something to work out what it is we really want to build.​

> 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.

​I agree. I think that the nature of forward secrecy is different as well.
I can design a protocol that is FS to the keys of Alice and Bob but not
Carol. I can also FS different keys at different times. ​

> 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.

​Well only the parts that address multi party protocols and I find the
literature is often barking up the wrong tree where requirements are

> 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.

​Quite, and maybe there is an approach in which we use one set of keys to
do a key agreement for authentication purposes and a second set of keys for
a FS mix-in.​