Re: [MLS] Use Cases for avoiding Forward Secrecy

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

If this group is not interested in open discussion, it might be in the
wrong standards organization.

Trying to shut down discussion of other requirements is a REALLY BAD
predictor of success in IETF.

Go talk to the DANE folk and see how that worked for them.

On Wed, Feb 28, 2018 at 5:28 PM, Dennis Jackson <[e-mail]>
wrote:

> > 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.
>
> _______________________________________________
> MLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mls
>