Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#252: Discuss Welcome/Commit coupling #255

Merged
merged 2 commits into from
Jun 13, 2024
Merged

#252: Discuss Welcome/Commit coupling #255

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0f6bf75
#252: Discuss Welcome/Commit coupling
Bren2010 Jun 5, 2024
6f91056
Update draft-ietf-mls-architecture.md
Bren2010 Jun 10, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 32 additions & 2 deletions draft-ietf-mls-architecture.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -795,6 +795,36 @@ If the Commit references an unknown proposal, group members may need to solicit
the Delivery Service or other group members individually for the contents of the
proposal.

### Welcome Messages

Whenever a commit adds new members to a group, MLS requires the committer to
send a Welcome message to the new members. Applications should ensure that
Welcome messages are coupled with the tie-breaking logic for commits, discussed
in {{strongly-consistent}} and {{eventually-consistent}}. That is, when multiple
commits are sent for the same epoch, applications need to ensure that only
Welcome messages corresponding to the commit that "succeeded" are processed by
new members.

This is particularly important when groups are being reinitialized. When a group
is reinitialized, it is restarted with a different protocol version and/or
ciphersuite but identical membership. Whenever an authorized member sends and
commits a ReInit proposal, this immediately freezes the existing group and
triggers the creation of a new group with a new `group_id`.

Ideally, the new group would be created by the same member that committed the
`ReInit` proposal (including sending Welcome messages for the new group to all
of the previous group's members). However this operation is not always atomic,
so it's possible for a member to go offline after committing a ReInit proposal
but before creating the new group. When this happens, it's necessary for another
Bren2010 marked this conversation as resolved.
Show resolved Hide resolved
member to continue the reinitialization by creating the new group and sending
out Welcome messages.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it is possible to design a client that does that, but it is also possible to design ones that always do generate the new group atomically. Is there a technical reason to NOT generate the ReInit Commit and create the new group as a single step?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's not a technical reason to make it not atomic. Like you say, it's possible, and doing so would avoid this issue. But I don't think it's something worth requiring


This has the potential to create a race condition, where multiple members try to
continue the reinitialization at the same time, and members receive multiple
Welcome messages for each attempt at reinitializing the same group. Ensuring
that all members agree on which reinitialization attempt is "correct" is key to
prevent this from causing forks.

# Functional Requirements

MLS is designed as a large-scale group messaging protocol and hence aims to
Expand Down Expand Up @@ -1099,8 +1129,8 @@ order for two different deployments based on them to interoperate.
- In cases where group operations are not encrypted, the DS has the ability to
observe and maintain a copy of the public group state. In particular, this
is useful for clients that do not have the ability to send the full public
state in a Welcome message when inviting auser or for client that need to
recover from a loss of their state. Such public state can contain privacy
state in a Welcome message when inviting a user, or for a client that needs to
recover from losing their state. Such public state can contain privacy
sensitive information such as group members' credentials and related public
keys, hence services need to be carefully evaluate the privacy impact of
storing this data on the DS.
Expand Down
Loading