Page MenuHomePhabricator

Implement endpoint on the keyserver to get one time keys and prekey to initialize olmsession
ClosedPublic

Authored by marcin on Apr 24 2023, 6:43 AM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 7, 6:04 AM
Unknown Object (File)
Tue, Nov 5, 10:06 PM
Unknown Object (File)
Tue, Nov 5, 10:06 PM
Unknown Object (File)
Tue, Nov 5, 10:06 PM
Unknown Object (File)
Tue, Nov 5, 8:57 AM
Unknown Object (File)
Tue, Nov 5, 8:57 AM
Unknown Object (File)
Tue, Nov 5, 4:35 AM
Unknown Object (File)
Sun, Nov 3, 7:24 PM
Subscribers

Details

Summary

This differential implements an endpoint on the keyserver to get data necessary to initialize olm session with the client.

Test Plan

Call commCoreModule.initializeCryptoAccount() (it is called in log-in-panel via nativeLogInExtraInfoSelector). This ensures notifications session is initialized. Then call this endpoint to get necessary data to initialize sesion for notifications. Pass obtained data to
commCoreModule.initializeNotificationsSession().

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

ashoat requested changes to this revision.Apr 24 2023, 8:21 AM

I think we'll need to find a way to synchronize any updates to Olm accounts / sessions so that we only do one such update at a time

keyserver/src/responders/keys-responders.js
57 ↗(On Diff #25607)

There is a serious issue here, which is that we are not returning a signed prekey. I created ENG-3754 to track

66 ↗(On Diff #25607)

There appears to be a serious risk of a data race here causing one update to overwrite another

This revision now requires changes to proceed.Apr 24 2023, 8:21 AM
keyserver/src/responders/keys-responders.js
37 ↗(On Diff #25607)

Let's name this getOlmNotifSessionInitializationDataResponder and only support notifications

57 ↗(On Diff #25607)

Clarification: this should be signed by the notif identity's signing key. The client will trust that, because it is inside the signed identity keys blob, which is itself signed by the primary identity's signing key

63 ↗(On Diff #25607)

Let's avoid sending these identity keys... instead, let's return the signed identity keys blob

keyserver/src/responders/keys-responders.js
37 ↗(On Diff #25607)

Done renaming

57 ↗(On Diff #25607)

Will be monitoring: https://linear.app/comm/issue/ENG-3754/signing-the-prekey. If it is not done by the time I want to land this diff, I will sign prekey here and send signature with the response to the client, where it will be verified with crypto::CryptoModule::verifySignature(...);

66 ↗(On Diff #25607)

Novel approach should mitigate the risk.

  1. Use transactional olm account updater.
  2. Rename to getOlm{Notifs}SessionInitializationData...`.
  3. Respond with SignedIdentityKeysBlob instead of plain identity keys.

Boilerplate to use dispatchActionPromise

ashoat requested changes to this revision.Apr 27 2023, 8:09 AM
ashoat added a subscriber: anunay.
ashoat added inline comments.
keyserver/src/responders/keys-responders.js
38 ↗(On Diff #25818)

We can remove this and assume the client will always want just a single one-time key

54 ↗(On Diff #25818)

We can call account.prekey_signature() here to get the prekey signature

62 ↗(On Diff #25818)

We'll need to do this for the content account as well

58 ↗(On Diff #25761)

Did you mean this?

lib/types/request-types.js
202 ↗(On Diff #25818)

Since this endpoint will only be used for a client to connect with the keyserver, I think we will always ask for a single one-time key, and we can remove GetOlmNotifsSessionInitializationDataRequest altogether

205–209 ↗(On Diff #25818)

Following the discussion in today's encryption sync, I think this type should look like this:

type OlmAccountSessionInitializationInfo = {
  +prekey: string,
  +prekeySignature: string,
  +oneTimeKey: string,
};
export type GetOlmSessionInitializationDataResponse = {
  +signedIdentityKeysBlob: SignedIdentityKeysBlob,
  +contentInitializationInfo: OlmAccountSessionInitializationInfo,
  +notifInitializationInfo: OlmAccountSessionInitializationInfo,
};
207 ↗(On Diff #25761)

Based on this comment on Linear, it appears that we will need to also include a prekey signature here. (Worth confirming with @anunay)

This revision now requires changes to proceed.Apr 27 2023, 8:09 AM

(Removing most reviewers to clear out their queues, feel free to re-add yourself if you're interested)

keyserver/src/responders/keys-responders.js
41 ↗(On Diff #25818)

We should rename this (and all related names) to not mention "Notifs" anymore, since it will have to initialize both OlmAccounts now

lib/types/request-types.js
205–209 ↗(On Diff #25818)

Looking at the Linear issues it looks like we don't need to send prekey signature anymore

lib/types/request-types.js
205–209 ↗(On Diff #25818)

Please ignore the comment above.

Return data for both accounts.

ashoat requested changes to this revision.May 2 2023, 9:59 AM

Great work here! Mostly requesting changes to get rid of the any type. You'll also potentially need to refactor the use of fetchCallUpdateOlmAccount following my feedback in D7568

keyserver/src/responders/keys-responders.js
50

My feedback here was not addressed

81

You should never submit a diff with any. If you do, you should always annotate and attempt to justify it. Please find a way to remove this any

117

Get rid of any

This revision now requires changes to proceed.May 2 2023, 9:59 AM

Replace any with generics

ashoat requested changes to this revision.May 5 2023, 5:55 AM
ashoat added inline comments.
keyserver/src/responders/keys-responders.js
114 ↗(On Diff #26098)

My feedback about any was not addressed here

This revision now requires changes to proceed.May 5 2023, 5:55 AM
This revision is now accepted and ready to land.May 5 2023, 9:05 AM