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.

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

Regularly rotate leaf node encryption keys #1108

Merged
merged 8 commits into from
Oct 4, 2024

Conversation

richardhuaaa
Copy link
Contributor

@richardhuaaa richardhuaaa commented Oct 3, 2024

This PR achieves two things:

  1. Before sending an application message on a new group, clients will always rotate their encryption keys first. The reason for this is that the first encryption key used on a group is derived from the client's key package - so if the key package is not rotated frequently enough, this safeguard prevents issues related to re-use across multiple groups.
  2. All clients will also rotate their encryption keys on a 30 day interval, assuming they are active on a given group. This helps with post-compromise security.

Other notes:

  1. I've consolidated all intent creation into a queue_intent() method. This makes it easier to add pre-intent and post-intent actions in the future, for example if we want to check for missing installations before publishing any intent.
  2. With OpenMLS's default configuration, any commit will rotate the encryption key. I've used a post-intent action to mark the encryption key as rotated in this scenario, so we don't perform any additional unnecessary rotations.

Copy link

graphite-app bot commented Oct 3, 2024

Your org has enabled the Graphite merge queue for merging into main

Add the label “queue” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge.

You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link.

@richardhuaaa richardhuaaa changed the title Rotate leaf node encryption keys Regularly rotate leaf node encryption keys Oct 3, 2024
@@ -265,7 +265,7 @@ where
})?;

// publish the intent
if let Err(err) = sync_group.publish_intents(&conn.into(), self).await {
if let Err(err) = sync_group.publish_messages(self).await {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

publish_intents will stop at the first commit - so if a key rotation or an add_missing_installations is queued up first, the message history reply won't actually be sent. Instead, use publish_messages after a prepare_message call, just like apps do.

))?;

if intent_kind != IntentKind::SendMessage {
conn.update_rotated_at_ns(self.group_id.clone())?;
Copy link
Contributor Author

@richardhuaaa richardhuaaa Oct 3, 2024

Choose a reason for hiding this comment

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

We update the timestamp here when the intent is queued, rather than when the commit is successful, because otherwise we may queue up multiple key rotations if the user sends multiple messages.

The intent is not technically successful at this point - it's possible that the commit publishing fails later on after a few retries. I'm assuming that this should be rare and not exploitable.

Copy link
Contributor

@insipx insipx left a comment

Choose a reason for hiding this comment

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

Nice! queue_intent should also prove useful for #1090

@richardhuaaa richardhuaaa marked this pull request as ready for review October 3, 2024 22:14
@richardhuaaa richardhuaaa requested review from a team as code owners October 3, 2024 22:14
@richardhuaaa richardhuaaa merged commit 7be92cb into nm/documentation-updates Oct 4, 2024
7 checks passed
@richardhuaaa richardhuaaa deleted the rich/rotate-keys branch October 4, 2024 04:19
@neekolas neekolas mentioned this pull request Oct 8, 2024
neekolas added a commit that referenced this pull request Oct 8, 2024
* Add comments

* Add comments and fix SCW verifier

* Update README

* Fix errors and warnings

* Regularly rotate leaf node encryption keys (#1108)

This PR achieves two things:
1. Before sending an application message on a new group, clients will always rotate their encryption keys first. The reason for this is that the first encryption key used on a group is derived from the client's key package - so if the key package is not rotated frequently enough, this safeguard prevents issues related to re-use across multiple groups.
2. All clients will also rotate their encryption keys on a 30 day interval, assuming they are active on a given group. This helps with post-compromise security.

Other notes:

1. I've consolidated all intent creation into a `queue_intent()` method. This makes it easier to add pre-intent and post-intent actions in the future, for example if we want to check for missing installations before publishing *any* intent.
2. With OpenMLS's default configuration, *any* commit will rotate the encryption key. I've used a post-intent action to mark the encryption key as rotated in this scenario, so we don't perform any additional unnecessary rotations.

* Fix conflicts

* Remove unused import

---------

Co-authored-by: Richard Hua <[email protected]>
Co-authored-by: Richard Hua <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants