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

[Eric Rescorla <[e-mail]>]

On Mon, Jul 23, 2018 at 8:40 AM, Richard Barnes <[e-mail]> wrote:

>
>
> On Fri, Jul 20, 2018 at 11:02 PM Eric Rescorla <[e-mail]> wrote:
>
>>
>>
>> On Fri, Jul 20, 2018 at 7:58 PM, Daniel Kahn Gillmor <
>> [e-mail]> wrote:
>>
>>> On Thu 2018-07-19 13:39:16 -0400, Joseph Lorenzo Hall wrote:
>>> > On Thu, Jul 19, 2018 at 12:45 PM Daniel Kahn Gillmor
>>> > <[e-mail]> wrote:
>>> >>
>>> >> 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)
>>> >
>>> > 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?
>>>
>>
>> I think it would be better if generally we did not.
>>
>
> 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.
>

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.



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

Don't look at me.

-Ekr