Subject: [MLS] Group ID

From: Marek Jankowski <[email-masked]>
Date: Tue, 11 Jun 2019 16:33:15 +0200

Hi,
Regarding some issues that were raised in the last couple of months, I
wonder if we should hide the group ID from the DS. I think the group ID is
valuable metadata -- the DS may keep track of it and by that identify
sudden changes in the traffic, which may leak information.
Please consider the following alternatives:
group_id[n] = HKDF-Expand-Label(confirmation_key[n-1],group_id[n-1],
"group_id", 4)
I am aware it does not support reordering, But I'm sure one can figure an
alternative that does.

Marek.

---

From: Raphael Robert <[email-masked]>
Date: Wed, 5 Jun 2019 09:59:46 +0200

Hi Marek,

> I am aware it does not support reordering, But I'm sure one can figure an alternative that does.

We looked into doing exactly that. Server-side ordering is unfortunately a hard requirement for TreeKEM, so this is an open issue. We’d be happy to hear about a proposal that covers both problems!

Raphael

> On 11 Jun 2019, at 16:33, Marek Jankowski <[email-masked]> wrote:
> 
> Hi,
> Regarding some issues that were raised in the last couple of months, I wonder if we should hide the group ID from the DS. I think the group ID is valuable metadata -- the DS may keep track of it and by that identify sudden changes in the traffic, which may leak information.
> group_id[n] = HKDF-Expand-Label(confirmation_key[n-1],group_id[n-1], "group_id", 4)
> I am aware it does not support reordering, But I'm sure one can figure an alternative that does.
> 
> Marek.
> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls

---

From: Richard Barnes <[email-masked]>
Date: Wed, 5 Jun 2019 13:29:00 -0700

Like Raphael, I'm not concerned about the ordering requirement, since we
already have an ordering requirement.  Note, however, that whatever
identifier is used here will probably have to be stable within an epoch, so
the DS will still be able to see traffic volumes within an epoch.  The DS
may also be able to use time correlations to infer which opaque groupID
values represent the same group.

That still seems like it makes it harder for the DS to be malicious, so it
seems worthwhile to me.  Benjamin Beurdouche had raised a similar idea
earlier, of replacing the (groupID, epoch) pair with a single ID that is
opaque to the DS.  I'm increasingly thinking that that's probably the way
to go.  Marek / Benjamin, if you'd like to update PR#152 to do this, that
could help move this along.

I wonder if we still want some constant group ID value, even if it's known
only to group members.  No concrete

On Wed, Jun 5, 2019 at 1:00 AM Raphael Robert <raphael=
[email-masked]> wrote:

> We looked into doing exactly that. Server-side ordering is unfortunately a
> hard requirement for TreeKEM, so this is an open issue. We’d be happy to
> hear about a proposal that covers both problems!
>
> Raphael
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 5 Jun 2019 13:29:58 -0700

Sorry, hit "send" prematurely.

> could help move this along.

https://github.com/mlswg/mls-protocol/pull/152

> only to group members.  No concrete

... need is occurring to me right now, but it seems like there might be
some utility in separating contexts.

--Richard

>> We looked into doing exactly that. Server-side ordering is unfortunately
>> a hard requirement for TreeKEM, so this is an open issue. We’d be happy to