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

On Fri, Jul 20, 2018 at 11:02 PM Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Fri, Jul 20, 2018 at 7:58 PM, Daniel Kahn Gillmor <
> dkg@fifthhorseman.net> 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
>> > <dkg@fifthhorseman.net> 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.

(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

>
> -Ekr
>
>
>>      --dkg
>>
>> _______________________________________________
>> MLS mailing list
>> MLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/mls
>>
>
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls
>