Re: [MLS] Use Cases for avoiding Forward Secrecy

[Jon Millican <[e-mail]>]

If the question is about whether MLS should support forward secrecy in the first place, I think consumer E2E messaging applications provide a good use case for this. The threat model that we tend to take here is that the user has limited trust in the service provider. In this situation, the security properties provided by TLS are almost moot, as TLS only protects you as far as the service provider anyway.

Ephemerality is a very common property in such apps, with the explicit goal that messages not be accessible after a certain period. Even without ephemerality, I believe that most messaging support message deletion. In such situations, forward secrecy is very desirable, as it ensures that if keys or any device state do leak at any moment (be it from an exploit, somebody imaging a device, or a temporary bug in the app itself), users’ old messages can at least remain secret, even if the provider had retained all of their ciphertexts. This also leads to a similar case for Post-Compromise Security, in that secrecy can be recovered even after any sort of key leakage: although in this case the argument applies even when no messages are ever deleted.

On 01/03/2018, 16:35, "MLS on behalf of Phillip Hallam-Baker" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

On Thu, Mar 1, 2018 at 10:11 AM, Russ Housley <[e-mail]<mailto:[e-mail]>> wrote:

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

This is similar to the approach used in some email environments.  The email message is decrypted for reading, and then encrypted in a separate archive key for storage.

Russ

​It is a valid approach and it might be the right approach.
​
​But what we have right now is a rather complex proposal that may or may not be correct and may or may not be addressing the real requirements and may or may not be addressing them in the most straightforward fashion.

So far I have seen a lot of defensive responses and one individual whose behavior was bullying. Now the fact that I cannot be bullied out of my opinions does not make ​the experience of people making personal attacks any more pleasant for me.

More importantly, I am concerned that what has been more or less explicitly stated is 'we have our proposal and if you don't like it then bog off'.

I don't think that language encourages honest debate about the limitations of the proposal or identifying the flaws.

I would much rather the IETF endorse no proposal than one that only navigates the process because a group of bullies shouted down anyone who was critical of it. We saw that happen with DANE we saw it happen with CBOR. CBOR does work but the consequence of shutting down the voices saying that we needed a binary format that precisely matches the semantics of JSON is that we had to spin up a separate COSE working group to repeat the work of JOSE rather than simply apply the encoding.


The assumption of most here is that the requirements are easy and the cryptography is hard. That is precisely the wrong way round. If we really understand what the requirements are, the cryptography follows almost directly. It is getting to the understanding of the requirements that is the hard part.