From 325a0bf85ecd866a743155d783df830726ec2e17 Mon Sep 17 00:00:00 2001 From: EKR Date: Mon, 14 Aug 2023 17:49:27 -0700 Subject: [PATCH 1/3] Remove essentially all uses of "tree". In Eric Vyncke's DISCUSS he correctly notes that LeafNode is used without being defined. I fixed that by just removing the term but more generally the problem is the use of "tree" without it being defined. Obviously the tree is an important concept but that's really a matter for mls-protocol not mls-architecture which is just concerned with group state as an abstract structure. This change removes essentially all uses of the term tree except for: - In the final security considerations section where I think it's OK in context. - In this sentence "A maximum number of steps that clients will move a secret tree ratchet forward in response to a single message before rejecting it." I'm pretty sure that this can be reworded but I wasn't quite sure the best way. --- draft-ietf-mls-architecture.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/draft-ietf-mls-architecture.md b/draft-ietf-mls-architecture.md index 597c0f0..92997ab 100644 --- a/draft-ietf-mls-architecture.md +++ b/draft-ietf-mls-architecture.md @@ -1019,13 +1019,13 @@ interoperate. - Additional services may or may not be required depending on the application design: - - If assisted joining is desired (meaning that the ratchet tree is not + - If assisted joining is desired (meaning that the group state is not provided in Welcome messages), there must be a method to download the - ratchet tree corresponding to a group. + group state corresponding to a group. - If assisted joining is desired and the Delivery Service is not able to - compute the ratchet tree itself (because some proposals or commits are sent + compute the group state itself (because some proposals or commits are sent encrypted), there must be a method for group members to publish the updated - ratchet tree after each commit. + group state after each commit. - If external joiners are allowed, there must be a method to publish a serialized `GroupInfo` object (with an `external_pub` extension) that corresponds to a specific group and epoch, and keep that object in sync with @@ -1068,7 +1068,8 @@ deployments to interoperate: - Group IDs, as decided by group creators and used to uniquely identify a group. -- The `application_id` extension of a LeafNode. +- Associated with the per-user group state (specifically in + the `application_id` extension as defined in {{Section 5.3.3 of ?RFC9420}}). MLS requires the following policies to be defined, which restrict the set of acceptable behavior in a group. These policies must be consistent between @@ -1396,8 +1397,8 @@ the following compromise scenarios: The MLS protocol provides per-sender chains of AEAD keys that are generated from Group Secrets. These keys are used to protect MLS Plaintext messages which can be Group Operation or Application messages. The Group Operation messages offer -an additional protection as the secret exchanged within the TreeKEM group key -agreement are public-key encrypted to subgroups with HPKE. +an additional protection as the secrets exchanged within them +are public-key encrypted to subgroups with HPKE. ### Compromise of AEAD key material @@ -1571,8 +1572,7 @@ be a priority. Overall there is no way to detect or prevent these compromises, as discussed in the previous sections, performing separation of the application secret states can help recovery after compromise, this is the case for signature keys but -similar concern exists for the encryption private key used in the TreeKEM Group -Key Agreement. +similar concern exists for client's encryption private keys. > **RECOMMENDATION:** The secret keys used for public key encryption should be > stored similarly to the way the signature keys are stored, as keys can be used @@ -1866,7 +1866,7 @@ analyzed by {{BBN19}} (draft 7), {{ACDT21}} (draft 11) and {{AJM20}} (draft 12). Individual components of various drafts of the MLS protocol have been analyzed in isolation and with differing adversarial models, for example, {{BBR18}}, {{ACDT19}}, {{ACCKKMPPWY19}}, {{AJM20}}, {{ACJM20}}, and {{AHKM21}} analyze the -ratcheting tree as the sub-protocol of MLS that facilitates key agreement, +ratcheting tree sub-protocol of MLS that facilitates key agreement, {{WPBB22}} analyzes the sub-protocol of MLS for group state agreement and authentication, while {{BCK21}} analyzes the key derivation paths in the ratchet tree and key schedule. Finally, {{CHK21}} analyzes the authentication and cross-group healing From 5e2292e9edb299cf72f8f7bdcadbd06272687075 Mon Sep 17 00:00:00 2001 From: Eric Rescorla Date: Sat, 21 Oct 2023 07:48:14 -0700 Subject: [PATCH 2/3] Update draft-ietf-mls-architecture.md Co-authored-by: Brendan McMillion --- draft-ietf-mls-architecture.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-mls-architecture.md b/draft-ietf-mls-architecture.md index 92997ab..ac54dd3 100644 --- a/draft-ietf-mls-architecture.md +++ b/draft-ietf-mls-architecture.md @@ -1068,7 +1068,7 @@ deployments to interoperate: - Group IDs, as decided by group creators and used to uniquely identify a group. -- Associated with the per-user group state (specifically in +- Application-level identifiers of public key material (specifically the `application_id` extension as defined in {{Section 5.3.3 of ?RFC9420}}). MLS requires the following policies to be defined, which restrict the set of From 292c6532820f78ebd0e688f1550dd66f67ddc32e Mon Sep 17 00:00:00 2001 From: EKR Date: Sat, 21 Oct 2023 07:48:57 -0700 Subject: [PATCH 3/3] Adopt Richard's suggestion --- draft-ietf-mls-architecture.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/draft-ietf-mls-architecture.md b/draft-ietf-mls-architecture.md index ac54dd3..e9cd982 100644 --- a/draft-ietf-mls-architecture.md +++ b/draft-ietf-mls-architecture.md @@ -1019,13 +1019,16 @@ interoperate. - Additional services may or may not be required depending on the application design: - - If assisted joining is desired (meaning that the group state is not - provided in Welcome messages), there must be a method to download the - group state corresponding to a group. - - If assisted joining is desired and the Delivery Service is not able to - compute the group state itself (because some proposals or commits are sent - encrypted), there must be a method for group members to publish the updated - group state after each commit. + + - Instead of distributing group information to a new members + entirely within a Welcome messages, an application may rely on + servers to store public information about the group, such as + group members' credentials and related public keys, and provide + this information to new members. (In such a system, Welcome + messages are still necessary to convey confidential information + about the group.) Such an application will require mechanisms for + new members to download the current information for a group, and + for members to update the information as the group evolves. - If external joiners are allowed, there must be a method to publish a serialized `GroupInfo` object (with an `external_pub` extension) that corresponds to a specific group and epoch, and keep that object in sync with