Subject: [MLS] Purpose of path_secret in the Welcome message?

From: Théophile Wallez <[email-masked]>
Date: Thu, 22 Apr 2021 13:49:14 +0200

Hello,

I am a PhD student currently writing a formalization of MLS, and I was 
wondering about the use of the `path_secret` field in `GroupSecrets`.
To communicate with the group during the current epoch, it is sufficient 
to know `joiner_secret`.
Also, thanks to the concept of unmerged leaves, a newly added leaf don't 
need to know any path secret to handle an UpdatePath: knowing a path 
secret early would simply result in the fact that the leaf could decrypt 
two different `encrypted_path_secret` in `UpdatePathNode`, which does 
not seem useful.

Can someone give me some intuition for when and why this optional 
`path_secret` is used?

Best,
Théophile.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 22 Apr 2021 08:29:37 -0400

Hi Théophile,

You're correct that the `path_secret` isn't used in the process of joining
the group (decrypting the Welcome message and initializing group state).
It is used the next time there's a group operation and an UpdatePath is
sent.  It's optional because the sender of an all-Add Commit message
doesn't have to send an Update Path.  In that case, the path above a
joiner's leaf will be all-blank; there's no path secret to communicate.

Hope that helps,
--Richard

On Thu, Apr 22, 2021 at 7:49 AM Théophile Wallez <[email-masked]>
wrote:

> _______________________________________________
> MLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mls
>

---

From: Théophile Wallez <[email-masked]>
Date: Thu, 22 Apr 2021 17:37:14 +0200

Hi Richard,

On 22/04/2021 14:29, Richard Barnes wrote:

> It is used the next time there's a group operation and an UpdatePath 
> is sent.

I don't get why this is true?
 From my understanding, a new leaf will be in the `unmerged_leaves` list 
of all the non-blank nodes above it [0]. Given this fact, the new leaf 
will be in the resolution of all the nodes above it, therefore the new 
leaf will be able to decipher the path secrets for the following 
UpdatePath without using the `path_secret` of the Welcome message.
Also, in the worst case the `path_secret` might correspond to the path 
secret of the root node (since it is the path secret of the lowest 
common ancestor of the leaf sending the Welcome message and the leaf 
receiving the Welcome message [1]), which would not be useful to process 
an UpdatePath message.

[0] 
https://messaginglayersecurity.rocks/mls-protocol/draft-ietf-mls-protocol.html#section-11.1.1-5.2
[1] 
https://messaginglayersecurity.rocks/mls-protocol/draft-ietf-mls-protocol.html#section-11.2.2-9.4.2.2

Thanks,
Théophile.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 22 Apr 2021 21:24:03 -0400

On Thu, Apr 22, 2021 at 11:39 AM Théophile Wallez <[email-masked]>
wrote:

> of all the non-blank nodes above it [0].

Ah, this might not be obvious from the spec, but the order of operations
for the committer and their tree is as follows:

1. Apply proposals - including adding joiners to unmerged_leaves
2. Generate and apply an UpdatePath

In that stage 2, the nodes on the committer's direct path are overwritten
-- including clearing unmerged_leaves, because the corresponding secret is
sent to all the leaves underneath that node.  Continuing members get the
path secret from the UpdatePath struct; new members get it from
GroupSecrets.path_secret.

As usual, happy to clarify the spec if it can be clearer on this point.

--RLB

> Given this fact, the new leaf

---

From: Théophile Wallez <[email-masked]>
Date: Fri, 23 Apr 2021 20:17:28 +0200

On 23/04/2021 03:24, Richard Barnes wrote:
> Ah, this might not be obvious from the spec, but the order of 
> operations for the committer and their tree is as follows:
>
> In that stage 2, the nodes on the committer's direct path are 
> overwritten -- including clearing unmerged_leaves, because the 
> corresponding secret is sent to all the leaves underneath that node.  
> Continuing members get the path secret from the UpdatePath struct; new 
> members get it from GroupSecrets.path_secret.
>

Thank you, this clarifies the use of `path_secret`!

Indeed, I thought it was done in the reverse order (generate and apply 
an UpdatePath, then apply proposals).

Théophile.