status-im
/
specs
mirror of https://github.com/status-im/specs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

x6: Add TODOs/questions

This commit is contained in:
Oskar Thoren 2019-04-26 13:53:00 +08:00
parent cf17849cb4
commit 151c2516d5
No known key found for this signature in database
GPG Key ID: 33AAFB33580C538E
1 changed files with 24 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
x6.md
View File

@ -141,8 +141,14 @@ Every client initially generates some key material which is stored locally:
- A signed prekey based on secp256k1 - $SPK$; - A signed prekey based on secp256k1 - $SPK$;
- A prekey signature - <i>Sig($IK$, Encode($SPK$))</i> - A prekey signature - <i>Sig($IK$, Encode($SPK$))</i>
TODO: Formatting is off here, not sure what this is supposed to be in Markdown. Assumes LaTeX?
Prekey bundles are exchanged through QR codes, contact codes, 1:1 or public chat messages. *We will be updating this document with information about bundle exchange through [ENS](https://ens.domains/) and [Swarm](https://swarm-guide.readthedocs.io/en/latest/introduction.html) as work progresses and technologies become more usable.* Prekey bundles are exchanged through QR codes, contact codes, 1:1 or public chat messages. *We will be updating this document with information about bundle exchange through [ENS](https://ens.domains/) and [Swarm](https://swarm-guide.readthedocs.io/en/latest/introduction.html) as work progresses and technologies become more usable.*
TODO: 'contact code' is not defined.
TODO: How do you know if you run out of prekeys? What happens?
TODO: See below on bundle retrieval, this seems like enhancement and parameter for recommendation
### 2.3. Bundle retrieval ### 2.3. Bundle retrieval
X3DH works by having client apps create and make available a bundle of prekeys (the X3DH bundle) that can later be requested by other interlocutors when they wish to start a conversation with a given user. X3DH works by having client apps create and make available a bundle of prekeys (the X3DH bundle) that can later be requested by other interlocutors when they wish to start a conversation with a given user.
@ -155,6 +161,8 @@ In the X3DH specification, a shared server is typically used to store bundles an
- Decentralized permanent storage (e.g. Swarm, IPFS). - Decentralized permanent storage (e.g. Swarm, IPFS).
- Whisper - Whisper
TODO: Comment, it isn't clear what we actually _do_. It seems as if this is exploring the problem space. From a protocol point of view, it might make sense to describe the interface, and then have a recommendation section later on that specifies what we do. See e.g. Signal's specs where they specify specifics later on.
Since bundles stored in QR codes or ENS records cannot be updated to delete already used keys, the approach taken is to rotate more frequently the bundle (once every 24 hours), which will be propagated by the app through the channel available. Since bundles stored in QR codes or ENS records cannot be updated to delete already used keys, the approach taken is to rotate more frequently the bundle (once every 24 hours), which will be propagated by the app through the channel available.
### 2.4. 1:1 chat contact request ### 2.4. 1:1 chat contact request
@ -163,6 +171,8 @@ There are two phases in the initial negotiation of a 1:1 chat:
1. **Identity verification** (e.g., face-to-face contact exchange through QR code, Identicon matching). A QR code serves two purposes simultaneously - identity verification and initial bundle retrieval; 1. **Identity verification** (e.g., face-to-face contact exchange through QR code, Identicon matching). A QR code serves two purposes simultaneously - identity verification and initial bundle retrieval;
1. **Asynchronous initial key exchange**, using X3DH. 1. **Asynchronous initial key exchange**, using X3DH.
TODO: I'd consider calling the first Trust Establishment and lnik to that document
#### 2.4.1. Initial key exchange flow (X3DH) #### 2.4.1. Initial key exchange flow (X3DH)
The initial key exchange flow is described in [section 3 of the X3DH protocol](https://signal.org/docs/specifications/x3dh/#sending-the-initial-message), with some additional context: The initial key exchange flow is described in [section 3 of the X3DH protocol](https://signal.org/docs/specifications/x3dh/#sending-the-initial-message), with some additional context:
@ -298,6 +308,8 @@ A peer is identified by two pieces of data:
1) An `installation-id` which is generated upon creating a new account in the `Status` application 1) An `installation-id` which is generated upon creating a new account in the `Status` application
2) Their identity whisper key 2) Their identity whisper key
TODO: What does this mean for account recovery? Wouldn't installation id be new then too? Is this the same as Device ID in Sesame?
## 3.1 Initializiation ## 3.1 Initializiation
A new session is initialized once a successful X3DH exchange has taken place. A new session is initialized once a successful X3DH exchange has taken place.
@ -313,6 +325,8 @@ On receiving a bundle from a given peer with a higher version, the old bundle sh
## 4. Multi-device support ## 4. Multi-device support
TODO: Not clear to me exactly how it differs from Sesame. The central place is fair, but it's also described as a 'server function', so elaborating on difference would be useful. How do they (or not) deal with account recovery btw? This seems like we might be doing different trade-offs (?)
Multi-device support is quite challenging as we don't have a central place where information on which and how many devices (identified by their respective `installation-id`) belongs to a whisper-identity. Multi-device support is quite challenging as we don't have a central place where information on which and how many devices (identified by their respective `installation-id`) belongs to a whisper-identity.
Furthermore we always need to take account recovery in consideration, where the whole device is wiped clean and all the information about any previous sessions is lost. Furthermore we always need to take account recovery in consideration, where the whole device is wiped clean and all the information about any previous sessions is lost.
@ -325,6 +339,8 @@ This mean that every time a new device is paired, the bundle needs to be updated
When a user adds a new account, a new `installation-id` will be generated. The device should be paired as soon as possible if other devices are present. Once paired the contacts will be notified of the new device and it will be included in further communications. When a user adds a new account, a new `installation-id` will be generated. The device should be paired as soon as possible if other devices are present. Once paired the contacts will be notified of the new device and it will be included in further communications.
TODO: What do we mean by 'account' exactly?
Any time a bundle from your $IK$ but different `installation-id` is received, the device will be shown to the user and will have to be manually approved, to a maximum of 3. Once that is done any message sent by one device will also be sent to any other enabled device. Any time a bundle from your $IK$ but different `installation-id` is received, the device will be shown to the user and will have to be manually approved, to a maximum of 3. Once that is done any message sent by one device will also be sent to any other enabled device.
Once a new device is enabled, a new contact-code/bundle will be generated which will include pairing information. Once a new device is enabled, a new contact-code/bundle will be generated which will include pairing information.
@ -333,12 +349,16 @@ The bundle will be propagated to contacts through the usual channels.
Removal of paired devices is a manual step that needs to be applied on each device, and consist simply in disabling the device, at which point pairing information will not be propagated anymore. Removal of paired devices is a manual step that needs to be applied on each device, and consist simply in disabling the device, at which point pairing information will not be propagated anymore.
TODO: What happens if a device is offline for a long time with prekeys?
## 4.2 Sending messages to a paired group ## 4.2 Sending messages to a paired group
When sending a message, the peer will send a message to any `installation-id` that they have seen, using pairwise encryption, including their own devices. When sending a message, the peer will send a message to any `installation-id` that they have seen, using pairwise encryption, including their own devices.
The number of devices is capped to 3, ordered by last activity. The number of devices is capped to 3, ordered by last activity.
TODO: So this is different from the active-inactive abstraction in Sesame? What does it mean for pairwise encryption to be used for each device? Is there a different symmetric key for each device? How does that change the state in the ratched work? Are they separate sessions?
## 4.3 Account recovery ## 4.3 Account recovery
Account recovery is no different from adding a new device, and it is handled in exactly the same way. Account recovery is no different from adding a new device, and it is handled in exactly the same way.
@ -354,9 +374,12 @@ The same considerations apply as in [section 4 of the X3DH spec](https://signal.
**_TODO: Add any additional context here not covered in the X3DH and DR specs, e.g.:_** **_TODO: Add any additional context here not covered in the X3DH and DR specs, e.g.:_**
TODO: E.g. what?
### To be implemented ### To be implemented
TODO: Not clear what exactly is proposed as enhancement and what extra guarantees that would provide
## 1. Introduction ## 1. Introduction
#### 1.5.x. Contact request #### 1.5.x. Contact request
@ -572,4 +595,4 @@ TODO: this requires more detail
- The protocol requires whisper relay servers and mailservers currently. - The protocol requires whisper relay servers and mailservers currently.
- The larger the number of whisper relay servers, the better the transport security but there might be potential scaling problems. - The larger the number of whisper relay servers, the better the transport security but there might be potential scaling problems.
- Mailservers act to provide asyncronicity so users can retreive messages after coming back from an offline period. - Mailservers act to provide asyncronicity so users can retreive messages after coming back from an offline period.