Subject: [MLS] Use Cases for avoiding Forward Secrecy

From: Dave Cridland <[email-masked]>
Date: Wed, 28 Feb 2018 17:14:16 +0000

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.

---

From: Raphael Robert <[email-masked]>
Date: Wed, 28 Feb 2018 18:31:25 +0100

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 <[email-masked]> wrote:
> 
> Hi folks,
> 
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 28 Feb 2018 13:18:41 -0500

​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 <[email-masked]> 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
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 28 Feb 2018 21:16:24 +0000

Hiya,

> 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.

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 28 Feb 2018 16:58:50 -0500

> always need to have some kind of fallback to handle cases where

​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.

---

From: Dennis Jackson <[email-masked]>
Date: Wed, 28 Feb 2018 22:28:00 +0000

> 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 <[email-masked]> wrote:

> On Wed, Feb 28, 2018 at 4:16 PM, Stephen Farrell
> <[email-masked]> wrote:
> 
> >
> > Hiya,
> >
> > > 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.
> >
> team. At that point, Doug needs access to all documents and
> discussions related to the project, including:
> 
> ​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.
> 
> 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.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 28 Feb 2018 17:52:39 -0500

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.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 28 Feb 2018 22:56:22 +0000

> Sorry, why is transport layer security not sufficient between you

Because it's not a single hop.

Supposing my tax authority uses XMPP, for example, and so has (in my
case) hmrc.gov.uk as an XMPP domain. I use some commercialish XMPP
provider. I don't want my provider to be able to read my tax messages,
nor do I want them archived in plaintext on the server (although I
probably do want a verifiable record). Meanwhile, HMRC wants to keep
an archived, but secured, copy at their end, viewable by their
organisation.

> securing communications between a person and a service provider.

I'm not suggesting they should be.

I am suggesting that it might be nice if my options were not simply FS or FO.

(Besides which, the archives in a non-FS situation gain some security
guarantees, too).

> always need to have some kind of fallback to handle cases where

Assume a FS-only message transfer. In that case, how do we recover
missing messages? We have to transport those from another device that
has them. That's a perfectly reasonable concept, and one that has been
tried before in Skype. Unfortunately, as mobile devices replaced
desktop/laptop combinations as the dominant device, they switched away
from the design back to centrally-held archives since the clever
synchronisation options simply didn't work.

Of course, there are users who prefer the trade-off of higher security
and no (or limited) archives. Such users would, one hopes, be warned
about the change in security should they enter into a conversation
with someone who cannot (or will not) support FS.

Dave.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 28 Feb 2018 18:03:31 -0500

> indeed the current MLS draft.

​No it is completely correct. The P in PFS stands for Perfect .

If Alice creates a message for Bob using only her knowledge of Bob's public
key then it is not going to be PFS because a compromise of Bob's private
key is a breach.

What Signal is doing is sending messages based on Bob's key plus state from
previous communications that Alice and Bob have stored. Now that is
providing some form of Forward Secrecy but only a marketing person would
claim it was 'Perfect'.

​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.​

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Feb 2018 15:18:25 -0800

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 28 Feb 2018 18:25:58 -0500

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.

---

From: Dennis Jackson <[email-masked]>
Date: Wed, 28 Feb 2018 23:41:04 +0000

> ​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).

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

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. 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. 

On Wed, 28 Feb 2018 18:03:31 -0500
Phillip Hallam-Baker <[email-masked]> wrote:

> On Wed, Feb 28, 2018 at 5:28 PM, Dennis Jackson
> <[email-masked]> 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.
> >
> If Alice creates a message for Bob using only her knowledge of Bob's
> public key then it is not going to be PFS because a compromise of
> Bob's private key is a breach.
> 
> What Signal is doing is sending messages based on Bob's key plus
> state from previous communications that Alice and Bob have stored.
> Now that is providing some form of Forward Secrecy but only a
> marketing person would claim it was 'Perfect'.
> 
> ​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.​

---

From: Jon Millican <[email-masked]>
Date: Wed, 28 Feb 2018 23:58:02 +0000

One benefit to the ratcheting approach in the proposal is the immediate lock-out you get when a participant is evicted from a group. This is a different property from forward secrecy; but if we do wish to have this benefit in the protocol then I believe that we will have to be tolerant to mutations of message keys, and that any mechanism to retrieve message history or escrow messages would therefore have to tolerate messages being encrypted with arbitrarily many keys. If you can support this for eviction-triggered key mutations, I feel like it wouldn’t be much of a stretch to make it work on top of a forward secret protocol.

Of course, one possible set of requirements could tolerate evicted group members retaining access to the group encryption keys – which would render my above point moot – but this would feel to me like quite a strange security property to have.

On 28/02/2018, 23:19, "MLS on behalf of Eric Rescorla" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi folks,

Dave.

_______________________________________________
MLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mls&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=M0CVEJydBVUX_bvEqMa84Q&m=qL8XwY4DK13If0zpbmt6pcSE3iEl5EbKT0FY7L_a_-Q&s=0RrXaJNm0QXmkrg5W9sRhP6fd6iwfiK3Hpq7EPpfmjs&e=>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 1 Mar 2018 00:06:58 +0000

Hiya,

> an archived, but secured, copy at their end, viewable by their

I see no evidence that revenue.ie would ever prefer to handle
tax information via any intermediary when they have the option
to provide a URL to a tax payer or their agent. But perhaps you
do have a convincing use-case along those lines. If so, then I'd
say describing that, rather than asking to back off from forward
secrecy, might be a better approach at this stage (even if your
concern is really with the FS aspects of current MLS proposals).

> I'm not suggesting they should be.

FWIW, that's how I read your message. Apologies if I misread it.

> I am suggesting that it might be nice if my options were not simply FS or FO.

FO?

> (Besides which, the archives in a non-FS situation gain some security

Again, specifics there would be useful. I can't evaluate the
sentence above.

> missing messages? 

I've no idea. But MLS isn't aiming to provide interoperable messaging
(sadly but understandably IMO), so that seem a tad out of scope, as
ekr pointed out.

> We have to transport those from another device that

I'm fine if MLS is only usable by some subset of interpersonal
messaging applications myself, even if the precise delineation of
the set of applications that can use MLS isn't precisely known.
(So long as there are a useful set of applications that can use
MLS.)

> with someone who cannot (or will not) support FS.

I don't think such subtle differences are at all desirable myself.

Cheers,
S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 28 Feb 2018 20:10:17 -0500

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

> 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.​

> 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

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.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 28 Feb 2018 21:21:53 -0500

Re-adding the list.

On Feb 28, 2018 18:21, "Richard Barnes" <[email-masked]> wrote:

> Hey Dave,
>
> Thanks for the feedback.  This is a good point to clarify.  It had also
> crossed my mind, as the product I work with most in my day job also has
> retention features.
>
> However, I kind of chose not to worry about it, under the following
> theory: You can always build a non-forward-secret system out of a
> forward-secret one.  For example, you could use the FS keys to encrypt a
> long-term key, passing it forward across FS boundaries.
>
> So kind of like Raphael was saying, I figured an application with
> history-sharing or retention needs could wrap see extra stuff around MLS to
> dial back the appropriate knobs.
>
> --Richard
>
> On Feb 28, 2018 12:14, "Dave Cridland" <[email-masked]> wrote:
>
>> Hi folks,
>>