Subject: [MLS] protections for MLS "handshake" messages

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 19 Jul 2018 12:45:13 -0400

In today's session, there seemed to be an open question that wasn't
explicitly addressed, so i wanted to raise it on the list.

for lack of a better term, we're dividing MLS messages into
"application" messages and "handshake" messages.  (i think we need
a better term for "handshake", but i'll use it here for consistency with
the current discussion)

I believe we should provide encrypted cover, and a mechanism for padding
of handshake messages, not just for application messages.

We want encrypted cover because i'd like the DS not to be able see
whether a given message is a handshake message or an application
message.

and if it is a handshake message, i want to be able to make a handshake
message that shows up for a group of K people to look the same to an
observer as a handshake for a group of K+1 people (this motivates the
request for padding.

I recognize that some of this might come into conflict with richard
barnes' vision of a DS that stores a cache of messages from each
participant in a given group for future replay -- so i think we need
further dicsussion on it.

        --dkg

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 19 Jul 2018 13:39:16 -0400

> a better term for "handshake", but i'll use it here for consistency with

What about "content" and "keying" messages as new names?

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 20 Jul 2018 22:58:26 -0400

> What about "content" and "keying" messages as new names?

I'm maybe a little reluctant to use "content", because it seems too
generic, and too allusive to the elusive "content/metadata" boundary.
But i'd be fine with "application" and "keying" as the nomenclature.

But I'm more interested in what people think about protecting these
messages (or even the distinction between the two categories of message)
from the DS itself.  Is there a reason that we need to expose to the DS
that keying updates are happening?

     --dkg

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Jul 2018 20:01:57 -0700

> that keying updates are happening?

I think it would be better if generally we did not.

-Ekr

>      --dkg
>
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 23 Jul 2018 11:40:29 -0400

On Fri, Jul 20, 2018 at 11:02 PM Eric Rescorla <[email-masked]> wrote:

>
>
> On Fri, Jul 20, 2018 at 7:58 PM, Daniel Kahn Gillmor <
> [email-masked]> wrote:
>

I agree with the inclination here, but I think it's going to be difficult
given some other requirements, especially around UserAdd / new devices
joining without invitation.  For example:

1. MLS needs to operate asynchronously, e.g., allowing a UserAdd / new
device when all other members are offline
2. A new joiner is going to be able to authenticate the membership of the
group before it transmits

If we're going to enable both of those, then we're going to need whatever
information is used for authentication to be cached somewhere that is
reliably online.  And that information can't be encrypted, since you don't
know anything a priori about what new device might show up.

(Note TLS is in a different posture here, since it is (1) online and (2)
two-party.)

Contrapositively, if we're going to have a handshake that the DS can't
read, we're going to need to relax one of the two above requirements
(possibly others; not claiming to be comprehensive).  For example:

A. If you disallow UserAdd and thus require all members of the group to be
added via GroupAdd, then you can encrypt handshake messages just fine.
Even if you need to access them for authentication, you could arrange some
scheme of passing encryption keys to new members.

B. Even with UserAdd, you can make a key-passing scheme work as long as
you're willing to say that new participants can't authenticate the roster
until someone wakes up and sends them the handshake decryption key.  That
would offer new devices the choice of either transmitting without knowing
the roster or waiting to transmit.

I don't really see how you make a reasonable "new device" experience
without UserAdd, so if we're going to make a change here, it will probably
have to be in the vein of (B).

To brief notes to close:

- In case it's not obvious to people, there's no point to padding handshake
messages unless they're encrypted.

- What's with the hate over "handshake" and "application"?  It's the same
distinction that TLS makes.

--Richard

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Jul 2018 08:49:01 -0700

> know anything a priori about what new device might show up.

I think this is too nihilistic on too fronts:

1.Just because some group operations can't be hidden doesn't mean that none
of them can.
2. I'm not sure why you are assuming that MLS needs to operate
asynchronously. Lots of systems operate on an "invite" model where one
group member invites others. Clearly that member can send the invite
information to the other member (though of course there are race conditions.

Don't look at me.

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 23 Jul 2018 10:57:40 -0500

> information to the other member (though of course there are race conditions.

We're chartered to develop key establishment and message protocols with
properties including:

o Asynchronicity - Keys can be established without any
two participants being online at the same time

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Jul 2018 08:59:47 -0700

> two participants being online at the same time

I should have said "user add". See above for how many protocols work.

-Ekr

---

From: Richard Barnes <[email-masked]>
Date: Mon, 23 Jul 2018 12:37:40 -0400

On Mon, Jul 23, 2018 at 11:49 AM Eric Rescorla <[email-masked]> wrote:

> 1.Just because some group operations can't be hidden doesn't mean that
> none of them can.
>

Every group operation is going to change the leaf key associated with an
identity, so it's going to change the authentication information that a new
joiner will need.  At which point we're back in the soup.

> information to the other member (though of course there are race conditions.

The invite model is common, but not ubiquitous.  With XMPP MUCs, for
example, users can just show up uninvited.  Maybe we don't want to support
those cases, or we're OK making them not-async, but we should be deliberate
about it.

There are also use case that the invite model can't cover, namely where
it's not possible for one of a user's devices (one member in your phrasing)
to pass the necessary information to a new member.  Old phone's dead /
dropped in the ocean / on a different continent / etc.

If you want to address that use case without UserAdd, you effectively need
for the application to provide a "sync across user's devices" service.  And
it's not totally clear to me that that would be sufficient.  For example,
you might need to also require that the handshake encryption key be
constant, so that a cached copy wouldn't go stale.

--Richard

>
>
> - In case it's not obvious to people, there's no point to padding
> handshake messages unless they're encrypted.
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 23 Jul 2018 15:24:52 -0400

On Mon 2018-07-23 15:17:20 -0400, Daniel Kahn Gillmor wrote:
> On Mon 2018-07-23 08:49:01 -0700, Eric Rescorla wrote:

apologies, i guess this should have been attributed to Richard Barnes,
not to ekr.  I blame confusion based on ekr's quoting style, but my
response remains the same regardless of the origin of the question.

         --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 23 Jul 2018 15:17:20 -0400

> distinction that TLS makes.

"handshake" is something that implies a meeting or a conversational
setup.  here, we're talking about ongoing key updates as well as
membership changes.  "handshake" also implies two parties (if there are
three-party handshake protocols in the real world, i'm unaware of them).
So for both those reasons, i think it's inappropriate for the MLS
context.

I've also argued already on this list that MLS should be *distancing*
itself from TLS, not trying to mimic it.  (I don't even think the name
MLS is appropriate, and i think we should change it to something that
doesn't sound like TLS)

People that want a secure two-party protocol with well-understood
security guarantees *should* use TLS, not whatever MLS turns out to be.
I definitely want us to *discourage* people from using MLS where TLS
would suit their use case better.

Let's not try to make these protocols too analogous, lest we confuse
people and encourage people to turn TLS into a multi-party scheme.

      --dkg

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 23 Jul 2018 13:45:06 -0700

> > distinction that TLS makes.

Hi DKG,

You're quoting Barnes here, not me.

-Ekr