Re: [MLS] Use Cases for avoiding Forward Secrecy

The scope of the proposal, you mean.

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.

Having been involved in the IPSEC effort and seen where the insistence on
'strong security guarantees' led there, I want to see every security
requirement backed by a use case. Because what happened with IPSEC was we
ended up with a protocol that did not work in the real world because it had
been intentionally designed to be hostile to NAT and did not address a long
list of real world security issues.

On Wed, Feb 28, 2018 at 12:31 PM, Raphael Robert <raphael@wire.com> wrote:

> Hi Dave,
>
> Mandatory retention and UX are valid points of course. The scope of MLS is
> however to provide strong security guarantees like FS on the other hand.
> Re-using the same encryption key is something applications that use MLS can
> on the layer above the messaging protocol: the “application layer”. This
> would allow application developers to take that decision independently for
> the specific use cases they want to cater for.
>
> Raphael
>
> > On 28 Feb 2018, at 18:14, Dave Cridland <dave@cridland.net> wrote:
> >
> > Hi folks,
> >
> > While I'm really pleased to see MLS, and I generally like the idea of
> > Forward Secrecy, there's a couple of use cases where it might be worth
> > avoiding. Feel free to correct me if these are in fact possible with
> > Forward Secrecy. Both these relate to archival access to past
> > messages:
> >
> > * UX - Some users (actually all of them) would like to be able to
> > install client software on a new device and have their historical
> > messages available to them. Most "business" messaging systems seem to
> > work this way, as well as a number of consumer-grade systems. The
> > nature of Forward Secrecy means that an archive would need to be held
> > on one device and re-sent to another through the network, which is
> > trickier to manage, and is reliant on multiple devices being online at
> > overlapping times. Alternately, the archival copy might be re-uploaded
> > to the server using a static encryption key, I suppose, which would
> > rather spoil the point.
> >
> > * Retention - Many business and government deployments have mandatory
> > retention requirements. An example is MIKEY-SAKKE, promoted in part by
> > the UK Government for its own communications, which uses mandatory key
> > escrow to keep an archived copy of the messages accessible to the
> > business units involved. An advantage of the SAKKE system is that it
> > allows the key escrow to be offline, limiting attack opportunities.
> >
> > 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.
> >
> > None of this is to say that Forward Secrecy should be avoided
> > entirely, of course.
> >
> > Dave.
> >
> > _______________________________________________
> > MLS mailing list
> > MLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/mls
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>