View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007215 | GNUnet | messenger service | public | 2022-04-01 14:48 | 2023-10-18 17:47 |
| Reporter | thejackimonster | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | assigned | Resolution | open | ||
| Product Version | Git master | ||||
| Summary | 0007215: Indirect message receivement without permission | ||||
| Description | The permission model of messages in the messenger service is currently still not fully trustworthy. The permissions should imply that members of a room have only access to messages which were sent after they joined the room excluding messages sent before that event. This functionality will utilize the message graph and it is unrelated to timestamps which could be false. The current state of this system makes it impossible to receive an older message from another peer in the room via an own request even if you know the required hash to specify this older message. However if another member requests an older message, it will usually be propagated to all other peers making the exchange of missed messages more efficient. This can lead to older messages arriving at newer members without any form of encryption preventing them from reading. The only mechanism which might prevent a client from having access to those messages is that their signatures might not be verifiable because they miss older keys from the sender. There are multiple potential solutions: 1. Requested messages could be sent privately instead of propagating them publicly. (less efficient: messages might need to be sent to each member individually) 2. Messages need to be sent encrypted with a newly exchanged key for a group session describing a state of members currently in a room. This key needs to be generated, exchanged (probably privately) and potentially chained to avoid duplicate group sessions for the same state. The key will change each time a member joins and leaves to avoid not permitted access to messages. | ||||
| Additional Information | Both solutions require sending messages privately which were potentially not sent by the peer which wants to propagate them. However the PRIVATE message kind does not allow sending messages sent originally by other room members privately because this might allow identity theft. So a solution like mentioned above would require a new kind of message - most likely. Group sessions seem to be the favored solution but they will probably not work for all messages. JOIN and LEAVE messages should not be encrypted with such a group session key and other messages in the member session history (providing member details like name, current id and key) as well. So this functionality is mostly to reduce access to not permitted content messages (if so called) like TEXT, FILE and similar. Exchanging such a group session key will therefore require a new kind of message as well as a new kind of message encrypting the inner content with the group session key (similar to PRIVATE messages but setting a group in a room as recipient). The most difficult part is generating a group session key and exchanging it. (Maybe the consensus service can help with that.) | ||||
| Tags | No tags attached. | ||||
|
|
The MLS protocol claims to solve this issue. It uses so called epochs inside a group which describe a state of the group of a specific set members. It's very close to the 2nd potential solution I suggested. Investigating how MLS claims to solve the issues regarding such "group sessions" might help to find a way for proper implementation: https://www.rfc-editor.org/rfc/rfc9420.html |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-04-01 14:48 | thejackimonster | New Issue | |
| 2022-04-01 14:48 | thejackimonster | Status | new => assigned |
| 2022-04-01 14:48 | thejackimonster | Assigned To | => thejackimonster |
| 2022-09-15 18:05 | thejackimonster | Assigned To | thejackimonster => |
| 2023-10-18 17:47 | thejackimonster | Note Added: 0020592 |
