Conversation
jazzz
force-pushed
the
jazzz/inbox_xk0
branch
from
c47f593 to
1c4eb7d
Compare
osmaczko
left a comment
osmaczko
left a comment
There was a problem hiding this comment.
The specification might benefit from explicitly referencing the Chat Framework, for example by:
- Stating that Inbox is an Initialization Protocol as defined by the Chat Framework
- Referring to the
PreMessageas theIntroductionBundlefor this protocol (or documenting the mapping) - Clarifying that the out-of-band exchange of the
PreMessagefalls under the responsibility of the Discovery Protocol
| I -->> R: Subscribe | ||
|
|
||
| note over R,S: Send Out-of-Band | ||
| R ->> S : PreMessage(IK,EK,<delivery_address>) |
There was a problem hiding this comment.
Is PreMessage a concrete realization of an IntroductionBundle mentioned in the Chat Framework specification?
There was a problem hiding this comment.
Correct. That has been renamed. Will update
| R ->> S : PreMessage(IK,EK,<delivery_address>) | ||
|
|
||
| note over R,S: Sent In-Band | ||
| S ->> I : M1 |
There was a problem hiding this comment.
InboxHandshakeV1 is sufficient here. There is only one message type defined currently so yes M1 = InboxHandshakeV1 but that is not categorically true into the future.
This diagram is aimed at representing Message flow generically.
| - **ephemeral:** This field contains the remotes ephemeral public key. | ||
| - **key_ref:** This field contains the recipient key identifier used in the handshake. This value is 4 bytes long. | ||
| - **static:** this field contains the remotes static public key. This value is encrypted according to the noise protocol to hide the senders identity. |
|
|
||
| ## Implementation Suggestions (optional) | ||
|
|
||
| Recipients ephemeral key is not signed, and is susceptible to tampering by an active attacker during transit out of band. Implementors SHOULD keep the number of valid keys as little as possible. Revoking keys after a defined period of time, and only generating keys when needed minimizes the ability for an attacker to substitute weak keys |
There was a problem hiding this comment.
Is the unsigned EK risk here actually a confidentiality concern?Since the Recipient generates and tracks all their own EKs, a substituted EK would fail the key lookup on the Recipient side. So isn't this effectively a DoS (silently lost invite) rather than a "weak key" / forward secrecy issue?
Also, is the decision not to sign the ephemeral key still the case? According to logos-messaging/libchat#27, the IntroductionBundle is expected to contain a signature.
There was a problem hiding this comment.
You are correct to point out this inconsistency.
Originally This Spec used a XK0 Handshake which was removed in this commit in favor of X3DH.
This spec has not been fully updated.
There was a problem hiding this comment.
Since the Recipient generates and tracks all their own EKs, a substituted EK would fail the key lookup on the Recipient side. So isn't this effectively a DoS (silently lost invite) rather than a "weak key" / forward secrecy issue?
The issue here is when the moment of compromise occurs.
Signing of keys allows the compromise to be detected by the sender before any potentially secret material has been transmitted. Unsigned keys can only be detected by the recipient - which leaves a larger attack surface.
While conversation initialization would fail in both cases, unsigned keys provides the building blocks for more complex attacks.
2 participants
This PR adds a specification which describes a chat initialization protocol.
This replaces the previous effort #72 as the changes are substantial. This specification incorporates the feedback from the previous version - Specifically:
delivery_addressabstractioninbox_addressfor simplicityConversation_idsemantics to a implementation specific specification. #TODO: LinkIn addition it also: