Re: [MLS] Use Cases for avoiding Forward Secrecy

Phillip Hallam-Baker <> Wed, 28 February 2018 21:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 37530126D73 for <>; Wed, 28 Feb 2018 13:58:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id thWzNRv7qTjw for <>; Wed, 28 Feb 2018 13:58:52 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1211E126CF9 for <>; Wed, 28 Feb 2018 13:58:51 -0800 (PST)
Received: by with SMTP id y11so3732353otg.0 for <>; Wed, 28 Feb 2018 13:58:51 -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=eL1PoaqXggE6hwZbO0m37+5W0gk73c38m1a8jiqNMr0=; b=FZC6zxUaclEJOPMsPTumoOAubBhoqUHYcf2v6o598LtVnj11zN+VCqGtjzXermB1wh 9p7J62C3K+DNdIWfaBnzstZpRUDtzkwmSonIWMjA3k35THuc9+G/lfYrym7Y9vF5ZkSv lIOYeWl0YazZQZesjgz9FtiYRFmT6d5YL4sSoI6S9T3Rjb1Bs+ciUdJkJ2ovYfBdv7Z0 BzTD4pQaHzWu+naXvCKVXkQg0XK/IFu1HH/MyWMerLhxeg7xqM8bKjrwPm6jSiBhyMlm B91dq5WnC11TvJ2D8wJVwbazPom3az0Gs8dVhDPN2/ffMRfDnpRDEQCppJCX9F/Cp6ma ueSQ==
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=eL1PoaqXggE6hwZbO0m37+5W0gk73c38m1a8jiqNMr0=; b=BbrIfbSP4A0Hdzqml0P3Bsn934z7O6aqTN5i9yDzH4SfA7B8XrzjBA63YeqweHJJw5 eleBCkSCjdPAfaM8XAQgf3OoRnDmbppwtU38nmtTFWarbjKElRHG7wHOxYd5iGbChdz/ y3LmUUIMMeSa5GKeC+kwyTFmyLzahkiDDxwPz/z4WMt4q1mHgflQSYBuriRPYKFNYvZT 4137kD34kWl//A87BNrDmia/QzWAf6Yjtw5sKCRnKv+HamQ75tyeXt3K9PfU1yi7zUeD HL4Adz4nNYUvHe5ZOuPggtRd0LBbqRrjiP/0NtkigYlsfWMGwUKO+3BWzqHD+QN7BnMk v8bg==
X-Gm-Message-State: APf1xPB5FxxQH0YS8AugpuIKlVUjBgYcC3od0E3VrFio4e+dkpIyOtAI ImvlvJdT90jRMkv6nuoOvE5NYpxwbKequC+FB9E=
X-Google-Smtp-Source: AG47ELsFmhULVPwevaYrigCXZCu/5bWJjdTzwJEIYDiLfU/iyWQSy+mbulrEy5+70GWEWszC1SQY/ZEUO1Jjv2srvYw=
X-Received: by with SMTP id f62mr14706800otf.360.1519855131102; Wed, 28 Feb 2018 13:58:51 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 28 Feb 2018 13:58:50 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Phillip Hallam-Baker <>
Date: Wed, 28 Feb 2018 16:58:50 -0500
X-Google-Sender-Auth: A2qobZNC046UFi7A6hoJwW4b7J4
Message-ID: <>
To: Stephen Farrell <>
Cc: Dave Cridland <>,
Content-Type: multipart/alternative; boundary="94eb2c03c32633150e05664cd90c"
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: Wed, 28 Feb 2018 21:58:53 -0000

On Wed, Feb 28, 2018 at 4:16 PM, Stephen Farrell <>

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

​I posted a use case in which I do not want forward secrecy earlier.

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, including:

* All Word, Powerpoint, etc. documents.
* All Web sites and discussion forums.
* All group chats, video conferences, etc.​

​I have a system that can support this use case with end to end encryption.
Mallet can run all the online services. The only time an administration key
is required is when people are added to or removed from the group.

Using the term 'reduced' in relation to security properties is pejorative
and unhelpful. If we are having a discussion related to a project there
will be times when:

1) We want the discussion to be off the record with no permanent record.
2) We want the discussion to be on the record with a permanent record.

​These are disjoint use cases and they are both valid. ​They are even valid
for different discussions relating to a single project.

If we are working at the Transport layer, our conversation is always
synchronous and PFS does not constrain us. If however we are working at the
message layer, we will often want to support an asynchronous mode in which
one party sends some data and another picks it up later. That does not
prevent us working end to end but it does prevent us using PFS.