rfc/content/docs/rfcs/14/README.md

107 lines
4.2 KiB
Markdown
Raw Normal View History

---
Merge repo with rfc.vac.dev (#310) * Hugo init * Init Hugo book * Add basic README and title * Import RFC: 1/COSS * Move example content to dedicated folder * Basic menu * Tweak single layout * Fix base url and permalink * Basic index tweaks * Add netifly config * gitignore * 1/COSS: Add COSS lifecycle * Remove public artifact * Add basic numbers in menu * Empty READMEs init * Import mvds spec raw * 2/MVDS: Simplify * 3/REMOTE-LOG: Import * 3/REMOTE-LOG: Simplify * 4/MVDS-META: Import * 4/MVDS-META Simplify * Tweaks * 5/WAKU0: Import * 5: Simplify * 6/WAKU1: Import * 6/WAKU1: Simplify * 7/WAKU-DATA: Import * 7/WAKU-DATA: Simplify * 8/WAKU-MAIL: Import * 8/WAKU-MAIL: Simplify * Tweak * 9/WAKU-RPC: Import * 9/WAKU-RPC: Simplify * 10/WAKU2: Import * 10/WAKU2: Simplify * 11/WAKU-RELAY: Import * Tweaks * 11/WAKU-RELAY: Simplify * 12/WAKU-FILTER: Import * 12/WAKU2-FILTER: Simplify * 13/WAKU-STORE: Import * 13/WAKU-STORE: Simplify * 14/WAKU-MESSAGE: Import * 14/WAKU-MESSAGE: Simplify * 15/WAKU-BRIDGE: Import * 15: Simplify * 16: Import * 16: Simplify * 17: Import * 17: Simplify * 18: Import * 18: Simplify * 12: Bump update * 14: Bump update * 11: Bump update * 17: Bump update * 18: Bump update * 16: Bump update * Fix slug for 18 * Editor changes for 11, 12, 15 * Revert "Editor changes for 11, 12, 15" This reverts commit 5c32fe791bec57ca1d5326e0d2724339f12a784a. * Revert "Revert "Editor changes for 11, 12, 15"" This reverts commit ccd75131d72a1f1c43b701f445fe66ebd6857fc4. * Editor changes for 13, 2, 4 * Move current specs to archive * Update README * bump
2021-04-01 04:03:14 +00:00
slug: 14
title: 14/WAKU2-MESSAGE
name: Waku v2 Message
status: draft
editor: Oskar Thorén <oskar@status.im>
contributors:
- Sanaz Taheri <sanaz@status.im>
---
This specification provides a way to encapsulate messages sent over Waku with specific information security goals.
# Motivation
When sending messages over Waku there are multiple concerns:
- We may have a separate encryption layer as part of our application
- We may want to provide efficient routing for resource restricted devices
- We may want to provide compatibility with Waku v1 envelopes
- We may want payloads to be encrypted by default
- We may want to provide unlinkability for metadata protection
This specification attempts to provide for these various requirements.
2020-10-22 10:29:05 +00:00
# WakuMessage
A `WakuMessage` is what is being passed around by the other protocols, such as WakuRelay, WakuStore, and WakuFilter.
The `payload` field SHOULD contain whatever payload is being sent. See section below on payload encryption.
The `contentTopic` field SHOULD be filled out to allow for content-based filtering.
See [12/WAKU2-FILTER](/spec/12) and [13/WAKU2-STORE](/spec/13) for more details.
To enable a bidirectional bridge with Waku v1 see [15/WAKU2-BRIDGE](/spec/15) for further requirements on this field.
The `version` field MAY be filled out to allow for various types of payload encryption.
Omitting it means the version is 0.
The `timestamp` field MAY be filled out to signify the time at which the message is generated by its sender.
This field holds the Unix epoch time in nanoseconds.
Omitting it means the timestamp is unspecified.
2021-04-07 07:56:15 +00:00
## Payloads
Payloads are implemented using [protocol buffers v3](https://developers.google.com/protocol-buffers/).
```protobuf
2021-04-07 07:56:15 +00:00
syntax = "proto3";
message WakuMessage {
2021-04-07 07:56:15 +00:00
bytes payload = 1;
string contentTopic = 2;
2021-04-07 07:56:15 +00:00
uint32 version = 3;
sint64 timestamp = 10;
}
```
## Payload encryption
Payload encryption depends on the `version` field.
### Version 0
This indicates that the payload SHOULD be either unencrypted or that encryption is done at a separate layer outside of Waku.
### Version 1
This indicates that payloads MUST be encrypted using [WAKU2-PAYLOAD](/spec/26).
This provides for asymmetric and symmetric encryption.
Key agreement is out of band.
It also provides an encrypted signature and padding for some form of unlinkability.
### Version 2
This indicates that payloads MUST be encoded using [35/WAKU-NOISE](/spec/35).
This provides for symmetric encryption and
asymmetric key-exchange protocols.
# Differences from Whisper / Waku v1 envelopes
In Whisper and Waku v1, an envelope contains the following fields: `expiry, ttl, topic, data, nonce`.
Since Waku v2 is using libp2p PubSub, some of these fields can be dropped.
The previous `topic` field corresponds to `contentTopic`.
The previous `data` field corresponds to the `payload` field.
# Security Consideration
## Confidentiality, integrity, and authenticity
It is up to the application layer as to what level confidentiality, integrity and authenticity of the `payload` of `WakuMessage` matters.
Accordingly, the application layer shall utilize the encryption and signature schemes supported in WAKU2 to meet the application-specific privacy needs.
2022-01-19 03:00:20 +00:00
The set of supported schemes in WAKU2 is presented in [WAKU2-PAYLOAD](/spec/26).
## Reliability of the WakuMessage timestamp
The `timestamp` field in `WakuMessage` is set by the sender.
Because `timestamp` isn't independently verified, this field is prone to exploit and misuse.
It should not solely be relied upon for operations such as message ordering.
For example, a malicious node can arbitrarily set the `timestamp` of a `WakuMessage` to a high value so that it always shows up as the most recent message in a chat application.
Applications using the `WakuMessage`'s `timestamp` field are recommended to use additional methods for more robust message ordering.
An example of how to deal with message ordering against adversarial message timestamps can be found in the Status protocol, see [6/PAYLOADS](https://specs.status.im/spec/6#clock-vs-timestamp-and-message-ordering).
# Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).