Re: [MLS] Use Cases for avoiding Forward Secrecy

[Dennis Jackson <[e-mail]>]

> 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 <[e-mail]> wrote:

> On Wed, Feb 28, 2018 at 4:16 PM, Stephen Farrell
> <[e-mail]> 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.