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

From: Paul Rösler <[email-masked]>
Date: Fri, 20 Jul 2018 11:10:26 +0200

On 19.07.2018 21:00, [email-masked] wrote:
> Date: Thu, 19 Jul 2018 12:45:13 -0400
> From: Daniel Kahn Gillmor <[email-masked]>
> To: [email-masked]
> Subject: [MLS] protections for MLS "handshake" messages
> Message-ID: <[email-masked]>
> Content-Type: text/plain
> 
> 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.
Why and how is this possible for long application messages (i.e., how
long should a sensible padding be?)?

> 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.
Why? A network observer will see anyways to whom this message is routed.
I do not see a reasonable (i.e., practical) attacker model in which this
is a requirement that can be achieved with reasonable efficiency loss.
(E.g., a tree of depth 3 will always result in shorter path update
messages than a tree of depth 8; so where is the limit for the padding?)

Cheers,
Paul

> 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: "Katriel Cohn-Gordon" <[email-masked]>
Date: Fri, 20 Jul 2018 10:30:49 +0100

I certainly support adding fields for applications to pad however they like; that seems uncontroversial to me. In particular, if the application wants to pad out all messages to e.g. those of a 32k group, there should certainly be a field in the MLS packets for it.

> of handshake messages, not just for application messages.

As above, having a field for padding handshake messages seems uncontroversial; applications could use it however they choose.

Encrypted cover for the initial handshake seems circular: something has to go in plaintext first.

Encrypted cover for subsequent GroupAdd/Remove/KeyUpdate messages I'm not sure about: I guess it could be done by wrapping them into a message under the current group key, but it seems like some data might have to be on the outside in order for clients to figure out how to decrypt them. How much data needs to be hidden---would exposing a couple of sequence numbers and a group ID be ok? (This seems analogous to Signal's header encryption variant, which basically derives another key chain to encrypt packet headers.)

k