Re: [MLS] Use Cases for avoiding Forward Secrecy

Dennis Jackson <dennis.jackson@cs.ox.ac.uk> Wed, 28 February 2018 22:28 UTC

Return-Path: <dennis.jackson@cs.ox.ac.uk>
X-Original-To: mls@ietfa.amsl.com
Delivered-To: mls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3DF126FB3 for <mls@ietfa.amsl.com>; Wed, 28 Feb 2018 14:28:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eK1o9O5bRDUc for <mls@ietfa.amsl.com>; Wed, 28 Feb 2018 14:28:14 -0800 (PST)
Received: from relay14.mail.ox.ac.uk (relay14.mail.ox.ac.uk [163.1.2.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C5C126B6D for <mls@ietf.org>; Wed, 28 Feb 2018 14:28:14 -0800 (PST)
Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay14.mail.ox.ac.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <dennis.jackson@cs.ox.ac.uk>) id 1erACf-0003E6-jM; Wed, 28 Feb 2018 22:28:12 +0000
Received: from sth-1.gradacc.ox.ac.uk ([192.76.28.109] helo=T-200) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <dennis.jackson@cs.ox.ac.uk>) id 1erACe-000CdC-MC; Wed, 28 Feb 2018 22:28:00 +0000
Date: Wed, 28 Feb 2018 22:28:00 +0000
From: Dennis Jackson <dennis.jackson@cs.ox.ac.uk>
To: mls@ietf.org
Message-ID: <20180228222800.0a978ded@T-200>
In-Reply-To: <CAMm+LwjJxdTJcPBCNh3JsjDeWODFuS3FwUPz_ztvzKpkU7X8DA@mail.gmail.com>
References: <CAKHUCzxOwmPrpUUj6HSRMcxiXtRmT05OapeBQdRA49bSWum6yQ@mail.gmail.com> <f10d4e2c-7b4c-b841-eadf-056e1729c713@cs.tcd.ie> <CAMm+LwjJxdTJcPBCNh3JsjDeWODFuS3FwUPz_ztvzKpkU7X8DA@mail.gmail.com>
X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Oxford-Username: exet4027
X-Oxmail-Spam-Status: score=-0.0 tests=T_RP_MATCHES_RCVD -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
X-Oxmail-Spam-Level: /
Archived-At: <https://mailarchive.ietf.org/arch/msg/mls/ewRWoP3D8jVx66H5BXRSHskSmi8>
Subject: Re: [MLS] Use Cases for avoiding Forward Secrecy
X-BeenThere: mls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Messaging Layer Security <mls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mls>, <mailto:mls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mls/>
List-Post: <mailto:mls@ietf.org>
List-Help: <mailto:mls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mls>, <mailto:mls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Feb 2018 22:28:17 -0000

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

This is incorrect. You may want to review the design of Signal, or
indeed the current MLS draft.

> MLS is not chartered yet. We are discussing what the scope should be.
> It is really inappropriate to assert that has been decided before we
> have met to even discuss what the scope should be.​

The current proposal is designed to provide strong end to end
security for group messaging, with perfect forward secrecy and post
compromise security. 

If you don't agree with those design goals, I think you might be in the
wrong mailing list, as rather than being a bird of a feather, you appear
to be a bird of an all together different species. 

On Wed, 28 Feb 2018 16:58:50 -0500
Phillip Hallam-Baker <phill@hallambaker.com> wrote:

> On Wed, Feb 28, 2018 at 4:16 PM, Stephen Farrell
> <stephen.farrell@cs.tcd.ie> 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?
> >
> > 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.