11/WAKU2-RELAY: Relay protocol: System model extraction

[staheri14]

Problem

To extract out the system model of the relay protocol i.e.,

1. Entities and their roles
2. The data flow
3. The security assumptions (e.g., is any entity fully trusted)
4. The overall security guarantees (if any)
5. The potential constraints: To identify a clear set of constraints especially concerning performance that must be met by the spam-protection solution. For example, no central storage provider is allowed, the storage limit of nodes, etc.

This issue is part of the #189

Acceptance criteria

All the items listed above must be clearly specified and documented.

[staheri14]

The following summarizes the key points and features provided by the Libp2p PubSub (hence by the Waku Relay protocol) that seem relevant to enable spam protection on top of the Relay prtocol. This summary is based on https://github.com/libp2p/specs/tree/master/pubsub. Note that in the current version of the Relay protocol, not all of these features are implemented.

Messages
Messages embody the following fields:
1- from, seqno: the peer id of the origin sender of the message together with a sequence number
2- signature, key: a signature on the message, the key is the signature verification key
3- data
4- topicIDs

• Topic descriptor: various options and parameters of a topic can be defined through topic descriptor message. That includes encryption policy and authentication policy.
  • Authentication policy:
    • authorized keys: keys of users who can publish on the given topic
    • mode: No auth, with authentication keys, web of trust. Note that the mode affects the content of signature, key fields of the message
  • Encryption policy: Not a concern for the current issue
• Topics can be also attached with validator function with this signature (peer.ID, *Message) => bool where the return value is true if validation passes, and false otherwise.

---

Security cautions

• When users anonymity matters, the following fields of messages should be left unspecified from, seqno, signature, key
• When authentication matters, signature, key must be provided (the appropriate policy can be set using a topic descriptor)

[kdeme]

@staheri14 There was some previous discussion related to these fields ( 1 and 2) and this resulted in the decision to opt for StrictNoSign. (Actually, the discussion started before these signature policy options were added in the libp2p spec)
See also #149 and #150

[staheri14]

@staheri14 There was some previous discussion related to these fields ( 1 and 2) and this resulted in the decision to opt for StrictNoSign. (Actually, the discussion started before these signature policy options were added in the libp2p spec)
See also #149 and #150

Thanks @kdeme for letting me know! Thinking of anonymity as a concern, I also came to the conclusion that no signature should be included in the messages

[staheri14]

@kdeme wondering whether the from field is also avoided in the PubSub messages? I mean in the Relay protocol

[staheri14]

Items 1-4 are addressed in the first round of security analysis, item 5 is part of rln-relay specs. As all the requirements are addressed, I am closing this issue.