Re: [MLS] Use Cases for avoiding Forward Secrecy

[Phillip Hallam-Baker <[e-mail]>]

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.