From 4b2a6c68410d20f14a72bf21d63f97ccbe61c249 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Oskar=20Thor=C3=A9n?= Date: Thu, 5 Dec 2019 11:26:15 +0800 Subject: [PATCH] Security considerations (#60) * Initial cut * scalability ux section * moar * version and toc * fix port * clarify bloom * update bw usage link to version controlled * remove mvds refer * Update waku.md Co-Authored-By: Dean Eigenmann * Update waku.md Co-Authored-By: Dean Eigenmann --- waku.md | 72 +++++++++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 65 insertions(+), 7 deletions(-) diff --git a/waku.md b/waku.md index 9bfa47f5..960862b7 100644 --- a/waku.md +++ b/waku.md @@ -1,6 +1,6 @@ # Waku Whisper Specification -> Version 0.1.0 (Initial release) +> Version 0.1.1 (Initial release) > > Authors: Oskar Thorén oskar@status.im, Dean Eigenmann dean@status.im @@ -21,11 +21,17 @@ - [Additional capabilities](#additional-capabilities) - [Light node](#light-node) - [Mailserver and client](#mailserver-and-client) + - [Requesting messages](#requesting-messages) + - [Receiving historic messages](#receiving-historic-messages) - [Backwards Compatibility](#backwards-compatibility) - [Waku-Whisper bridging](#waku-whisper-bridging) - [Forwards Compatibility](#forwards-compatibility) -- [Security considerations](#security-considerations) -- [Implementation Notes](#implementation-notes) +- [Appendix A: Security considerations](#appendix-a-security-considerations) + - [Scalability and UX](#scalability-and-ux) + - [Privacy](#privacy) + - [Spam resistance](#spam-resistance) + - [Censorship resistance](#censorship-resistance) +- [Appendix B: Implementation Notes](#appendix-b-implementation-notes) - [Implementation Matrix](#implementation-matrix) - [Footnotes](#footnotes) - [Changelog](#changelog) @@ -339,16 +345,67 @@ Waku is a different subprotocol from Whisper so it isn't directly compatible. Ho It is desirable to have a strategy for maintaining forward compatibility between `waku/0` and future version of waku. Here we outline some concerns and strategy for this. - -## Security considerations +## Appendix A: Security considerations There are several security considerations to take into account when running Waku. Chief among them are: scalability, DDoS-resistance and privacy. These also vary depending on what capabilities are used, such as mailserver, light node, and so on. -### Light node privacy +### Scalability and UX + +**Bandwidth usage:** + +In version 0 of Waku, bandwidth usage is likely to be an issue. For more investigation into this, see the theoretical scaling model described [here](https://github.com/vacp2p/research/tree/dcc71f4779be832d3b5ece9c4e11f1f7ec24aac2/whisper_scalability). + +**Mailserver High Availability requirement:** + +A mailserver has to be online to receive messages for other nodes, this puts a high availability requirement on it. + +**Gossip-based routing:** + +Use of gossip-based routing doesn't necessarily scale. It means each node can see a message multiple times, and having too many light nodes can cause propagation probability that is too low. See [Whisper vs PSS](https://our.status.im/whisper-pss-comparison/) for more and a possible Kademlia based alternative. + +**Lack of incentives:** + +Waku currently lacks incentives to run nodes, which means node operators are more likely to create centralized choke points. + +### Privacy + +**Light node privacy:** The main privacy concern with light nodes is that directly connected peers will know that a message originates from them (as it are the only ones it sends). This means nodes can make assumptions about what messages (topics) their peers are interested in. -## Implementation Notes +**Bloom filter privacy:** + +By having a bloom filter where only the topics you are interested in are set, you reveal which messages you are interested in. This is a fundamental tradeoff between bandwidth usage and privacy, though the tradeoff space is likely suboptimal in terms of the [Anonymity](https://eprint.iacr.org/2017/954.pdf) [trilemma](https://petsymposium.org/2019/files/hotpets/slides/coordination-helps-anonymity-slides.pdf). + +**Mailserver client privacy:** + +A mailserver client has to trust a mailserver, which means they can send direct traffic. This reveals what topics / bloom filter a node is interested in, along with its peerID (with IP). + +**Privacy guarantees not rigorous:** + +Privacy for Whisper / Waku haven't been studied rigorously for various threat models like global passive adversary, local active attacker, etc. This is unlike e.g. Tor and mixnets. + +**Topic hygiene:** + +Similar to bloom filter privacy, if you use a very specific topic you reveal more information. See scalability model linked above. + +### Spam resistance + +**PoW bad for heterogenerous devices:** + +Proof of work is a poor spam prevention mechanism. A mobile device can only have a very low PoW in order not to use too much CPU / burn up its phone battery. This means someone can spin up a powerful node and overwhelm the network. + +**Mailserver trusted connection:** + +A mailserver has a direct TCP connection, which means they are trusted to send traffic. This means a malicious or malfunctioning mailserver can overwhelm an individual node. + +### Censorship resistance + +**Devp2p TCP port blockable:** + +By default Devp2p runs on port `30303`, which is not commonly used for any other service. This means it is easy to censor, e.g. airport WiFi. This can be mitigated somewhat by running on e.g. port `80` or `443`, but there are still outstanding issues. See libp2p and Tor's Pluggable Transport for how this can be improved. + +## Appendix B: Implementation Notes ### Implementation Matrix @@ -376,6 +433,7 @@ Notes useful for implementing Waku mode. | Version | Comment | | :-----: | ------- | +| 0.1.1 | Add security considerations appendix | | 0.1.0 (current) | Initial Release | ### Differences between shh/6 waku/0