vacp2p
/
rfc
mirror of https://github.com/vacp2p/rfc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add timestamp and ephemeral to dos protected topic (#598) 

* Add timestamp and ephemeral to dos protected topic

* Update test vectors
This commit is contained in:
Alvaro Revuelta 2023-05-05 09:52:36 +02:00 committed by GitHub
parent bce90564cb
commit 5fd51df2fe
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 23 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
content/docs/rfcs/57/README.md
View File

@ -375,21 +375,34 @@ This solution introduces two roles:
## Design requirements (publisher)
A publisher that wants to send messages that are relayed in the network for a given `protected-pubsub-topic` shall:
* be able to sign messages with the `private-key-topic` configured for that topic, producing a ECDSA signature of 64 bytes.
* be able to sign messages with the `private-key-topic` configured for that topic, producing a ECDSA signature of 64 bytes using deterministic signing complying with RFC 6979.
* include the signature of the `app-message-hash` (`message-signature`) that wishes to send in the `WakuMessage` `meta` field.
The `app-message-hash` of the message shall be calculated as the `sha256` hash of the following fields of the message:
```
sha256(concat(pubsubTopic, payload, contentTopic, timestamp, ephemeral))
```
Where fields are serialized into bytes using little-endian. Note that `ephemeral` is a boolean that is serialized to `0` if `false` and `1` if `true`.
## Design requirements (relay)
Requirements for the relay are listed below:
* A valid `protected-pubsub-topic` shall be configured with a `public-key-topic`, (derived from a `private-key-topic`). Note that the relay does not need to know the private key.
For simplicity, there is just one key per topic. Since this approach has clear privacy implications, this configuration is not part of the waku protocol, but of the application.
* Relay nodes should leverage the existing gossipsub validators that allow to `Accept` or `Reject` messages.
* Upon receiving a message, the node shall check the `meta` `WakuMessage` field. If empty, `Reject` the message.
Requirements on the gossipsub validator:
* Relay nodes should use the existing gossipsub validators that allow to `Accept` or `Reject` messages, according to the following criteria:
* If `timestamp` is not set (equals to 0) then `Reject` the message.
* If the `timestamp` is `abs(current_timestamp-timestamp) > MessageWindowInSec` then `Reject` the message.
* If `meta` is empty, `Reject` the message.
* If `meta` exists but its size is different than 64 bytes, `Reject` the message.
* If `meta` exists and has a size of 64 bytes, assert that `message-signature` is verified according to the ECDSA signature verification algorithm using `public-key-topic` and `app-message-hash`.
* If the signature does not verify correctly, `Reject` the message.
* If and only if the signature is verified, `Accept` the message.
* If `meta` does not successfully verifies according to the ECDSA signature verification algorithm using `public-key-topic` and `app-message-hash`, then `Reject` the message.
* If and only if all above conditions are met then `Accept` the message.
Other requirements:
* The node shall keep metrics on the messages validation output, `Accept` or `Reject`.
* (Optional). To further strengthen DoS protection, gossipsub [scoring](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#extended-validators) can be used to trigger disconnections from peers sending multiple invalid messages. See `P4` penalty.
This protects each peer from DoS, since this score is used to trigger disconnections from nodes attempting to DoS them.
@ -420,13 +433,15 @@ And the following message to send:
protected-pubsub-topic = pubsub-topic
contentTopic = content-topic
payload = 1A12E077D0E89F9CAC11FBBB6A676C86120B5AD3E248B1F180E98F15EE43D2DFCF62F00C92737B2FF6F59B3ABA02773314B991C41DC19ADB0AD8C17C8E26757B
timestamp = 1683208172339052800
ephemeral = true
```
The message hash and meta (aka signature) are calculated as follows.
```
app-message-hash = 0914369D6D0C13783A8E86409FE42C68D8E8296456B9A9468C845006BCE5B9B2
message.meta = B139487797A242291E0DD3F689777E559FB749D565D55FF202C18E24F21312A555043437B4F808BB0D21D542D703873DC712D76A3BAF1C5C8FF754210D894AD4
app-message-hash = 662F8C20A335F170BD60ABC1F02AD66F0C6A6EE285DA2A53C95259E7937C0AE9
message.meta = 127FA211B2514F0E974A055392946DC1A14052182A6ABEFB8A6CD7C51DA1BF2E40595D28EF1A9488797C297EED3AAC45430005FB3A7F037BDD9FC4BD99F59E63
```
Using `message.meta`, the relay node shall calculate the `app-message-hash` of the received message using `public-key-topic`, and with the values above, the signature should be verified, making the node `Accept` the message and relaying it to other nodes in the network.