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

[Richard Barnes <[e-mail]>]

Thinking on this a bit more, it seems like encrypting handshake messages
has some important operational implications.

Encrypting handshake messages implies that nobody who isn't authorized by a
member of the group can authenticate the list of members of the group.
Effectively, handshake message encryption kills UserAdd; the only way to
become a full member of the group is for someone in the group to add you.
On the one hand, I'll grant that this is a nice security property.  On the
other hand, it complicates things for the new-device case, since the new
device can't just join.

Arguably, this is not tragic.  An external party can always encrypt to the
group, as long as it doesn't care about knowing who's in the group.  And
until someone else transmits, the new device isn't missing anything. So you
could do something like the following:

- When new device wants to join, it send the group an AddRequest that
authenticates the new device and establishes a new key shared between it
and the group, without changing the group's state
- The next member to transmit MUST process the AddRequest and transmit
either a GroupAdd or an AddRequestDenied message

With that framework, you could have a similar UX to UserAdd, with the
difference that whatever the new joiner sends before the GroupAdd won't
have an authenticated list of recipients until the GroupAdd shows up.  Once
that arrives, however, the sender will be able to verify who received its
past messages.  (It does seem like it might be desirable to hide the past
membership of the group from current members, but even then, you could
selectively reveal the last generation.)

(It seems like there are some parallels here to DH-based 0xRTT in TLS 1.3,
though the exact analogy is escaping me.)

In any case, I would be interested in feedback from folks with messaging
apps as to whether a scheme like this seems like something that could be
implemented with reasonable UX.

--Richard


On Mon, Jul 23, 2018 at 4:45 PM Eric Rescorla <[e-mail]> wrote:

> n Mon, Jul 23, 2018 at 12:17 PM, Daniel Kahn Gillmor <
> [e-mail]> wrote:
>
>> On Mon 2018-07-23 08:49:01 -0700, Eric Rescorla wrote:
>> > - What's with the hate over "handshake" and "application"?  It's the
>> same
>> > distinction that TLS makes.
>>
>
> Hi DKG,
>
> You're quoting Barnes here, not me.
>
> -Ekr
>
> "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
>>
>
>