Re: [MLS] Use Cases for avoiding Forward Secrecy

Ekr

Well maybe. It depends on how much of the complexity of the proposed
protocol is coming from the attempt to achieve 'PFS' and also what the
protocol is in fact achieving.

In general, I like to see what the requirements are before jumping to
implementation.

Right now we seem to have a different key agreement approach for every
protocol. And we seem to be still doing key agreement the way we used to do
it in RSA even though we now use ECDH.

-Phb.

On Wed, Feb 28, 2018 at 6:18 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> Hi Dave,
>
> I certainly agree with you that there are use cases where applications
> might want to archive communications.
>
> Generally, I think the right answer to these, however, isn't to modify the
> messaging protocol but rather to add that functionality on the messaging
> app over the top. That also is a much easier way to do new device history
> sync
>
> -Ekr
>
>
> On Wed, Feb 28, 2018 at 9:14 AM, 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
>
>