Re: [MLS] Use Cases for avoiding Forward Secrecy

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

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

> > ​The cost of this shared state is far from trivial at the protocol
> > level as both the sending and receiving device have to be in
> > synchronization. What happens when Alice and Bob have a dozen
> > devices? Then we have 144 sets of shared state.​
>
> Phillip, it's clear you've read neither the MLS draft, nor the paper it
> is based on. For example: one of the key contributions is a reduction in
> the amount of shared state from O(n^2) to O(log n)
>

​It is pretty clear to me that you need to stop making assumptions about
what other people have read.

You are being very rude and you need to stop. NOW.


These are complicated issues and I for one would never assume that I had
written a paper that was clear enough for everyone to understand
immediately.

Further, it is far from clear to me that the paper addresses the multiple
devices per user as distinct from the multiple user problem. The draft has
all of two paragraphs on multiple devices. I have spent three years working
on the problem of sharing keys across multiple devices and it requires more
than two paragraphs to address all the issues, I am sure.​
​

​My exchange is O(n). If a participant drops out, the others can rekey
using the existing information.​



> > 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.
>
> The discussion on PFS has been done to death, both on the TLS mailing
> list and in numerous other places and I would hate to see us repeat it
> for little gain.


​Well hate away​.

This is a different problem to TLS because we have more than two parties
and it changes matters. One of the things I only just realized is that PFS
is not even a property of the protocol, it is a property of a key in the
exchange and not of the exchange itself.

I can modify my key exchange to support use cases in which the key exchange
has forward secrecy with respect to the keys of Alice and Bob but not Doug
or Carol. I am not sure why you would want to do that yet. But you can do
it.

​Actually, I do have a use case.

Let us say that we want FS with respect to each of the keys of Alice, Bob,
Carol and Doug but ​they don't all want to inject fresh FS information at
the exact same time. Let us say Alice has her key in a HSM while Bob is
using a soft key, Alice is sitting in a SOC and Bob is a field agent on
Moscow Rules. Bob probably wants for FS their key every ten minutes. Alice
might be good for a week.


> In the end, TLS 1.3 mandates that PFS be used in
> every connection. I find it hard to imagine that MLS will aspire
> to a weaker security goal than TLS, but as you say, it is for the
> group to decide.


If we have PFS at the TLS level, why do we need it at the messaging layer
as well? Or are you thinking you will be running your application over IP?


In general, I think that thinking about the protocol more is what leads to
higher security. Not simply insisting on a set of features we already know
how to implement.