Regularly rotate leaf node encryption keys #1108
Conversation
Your org has enabled the Graphite merge queue for merging into mainAdd 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
changed the title
| @@ -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 { | |||
There was a problem hiding this comment.
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())?; |
There was a problem hiding this comment.
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.
* 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 <rich@rkhua.com> Co-authored-by: Richard Hua <rich@xmtp.com>
This PR achieves two things:
Other notes:
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.