New RFC: 46/GOSSIPSUB-TOR-PUSH and 47/WAKU2-TOR-PUSH (#554)

content/docs/rfcs/46/README.md

@@ -0,0 +1,188 @@
+---
+slug: 46
+title: 46/GOSSIPSUB-TOR-PUSH
+name: Gossipsub Tor Push
+status: raw
+category: Standards Track
+tags:
+editor: Daniel Kaiser <danielkaiser@status.im>
+contributors:
+---
+
+# Abstract
+
+This document extends the [libp2p gossipsub specification](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
+specifying gossipsub Tor Push,
+a gossipsub-internal way of pushing messages into a gossipsub network via Tor.
+Tor Push adds sender identity protection to gossipsub.
+
+**Protocol identifier**: /meshsub/1.1.0
+
+Note: Gossipsub Tor Push does not have a dedicated protocol identifier.
+It uses the same identifier as gossipsub and works with all [pubsub](https://github.com/libp2p/specs/tree/master/pubsub) based protocols.
+This allows nodes that are oblivious to Tor Push to process messages received via Tor Push.
+
+# Background
+
+Without extensions, [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
+does not protect sender identities.
+
+A possible design of an anonymity extension to gossipsub is pushing messages through an anonymization network before they enter the gossipsub network.
+[Tor](https://www.torproject.org/) is currently the largest anonymization network.
+It is well researched and works reliably.
+Basing our solution on Tor both inherits existing security research, as well as allows for a quick deployment.
+
+Using the anonymization network approach, even the first gossipsub node that relays a given message cannot link the message to its sender (within a relatively strong adversarial model).
+Taking the low bandwidth overhead and the low latency overhead into consideration, Tor offers very good anonymity properties.
+
+# Functional Operation
+
+Tor Push allows nodes to push messages over Tor into the gossipsub network.
+The approach specified in this document is fully backwards compatible.
+Gossipsub nodes that do not support Tor Push can receive and relay Tor Push messages,
+because Tor Push uses the same Protocol ID as gossipsub.
+
+Messages are sent over Tor via [SOCKS5](https://www.rfc-editor.org/rfc/rfc1928).
+Tor Push uses a dedicated libp2p context to prevent information leakage.
+To significantly increase resilience and mitigate circuit failures,
+Tor Push establishes several connections, each to a different randomly selected gossipsub node.
+
+# Specification
+
+This section specifies the format of Tor Push messages, as well as how Tor Push messages are received and sent, respectively.
+
+## Wire Format
+
+The wire format of a Tor Push message corresponds verbatim to a typical [libp2p pubsub message](https://github.com/libp2p/specs/tree/master/pubsub#the-message).
+
+```
+message Message {
+  optional string from = 1;
+  optional bytes data = 2;
+  optional bytes seqno = 3;
+  required string topic = 4;
+  optional bytes signature = 5;
+  optional bytes key = 6;
+}
+```
+
+## Receiving Tor Push Messages
+
+Any node supporting a protocol with ID `/meshsub/1.1.0` (e.g. gossipsub), can receive Tor Push messages.
+Receiving nodes are oblivious to Tor Push and will process incoming messages according to the respective `meshsub/1.1.0` specification.
+
+## Sending Tor Push Messages
+
+In the following, we refer to nodes sending Tor Push messages as Tp-nodes (Tor Push nodes).
+
+Tp-nodes MUST setup a separate libp2p context, i.e. [libp2p switch](https://docs.libp2p.io/concepts/multiplex/switch/),
+which MUST NOT be used for any purpose other than Tor Push.
+We refer to this context as Tp-context.
+The Tp-context MUST NOT share any data, e.g. peer lists, with the default context.
+
+Tp-peers are peers a Tp-node plans to send Tp-messages to.
+Tp-peers MUST support `/meshsub/1.1.0`.
+For retrieving Tp-peers, Tp-nodes SHOULD use an ambient peer discovery method that retrieves a random peer sample (from the set of all peers), e.g. [33/WAKU2-DISCV5](/spec/33/).
+
+Tp-nodes MUST establish a connection as described in sub-section [Tor Push Connection Establishment](#connection-establishment) to at least one Tp-peer.
+To significantly increase resilience, Tp-nodes SHOULD establish Tp-connections to `D` peers,
+where `D` is the [desired gossipsub out-degree](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md#parameters),
+with a default value of `8`.
+
+Each Tp-message MUST be sent via the Tp-context over at least one Tp-connection.
+To increase resilience, Tp-messages SHOULD be sent via the Tp-context over all available Tp-connections.
+
+Control messages of any kind, e.g. gossipsub graft, MUST NOT be sent via Tor Push.
+
+### Connection Establishment
+
+Tp-nodes establish a `/meshsub/1.1.0` connection to tp-peers via [SOCKS5](https://www.rfc-editor.org/rfc/rfc1928) over [Tor](https://www.torproject.org/).
+
+Establishing connections, which in turn establishes the respective Tor circuits, can be done ahead of time.
+
+### Epochs
+
+Tor Push introduces epochs.
+The default epoch duration is 10 minutes.
+(We might adjust this default value based on experiments and evaluation in future versions of this document.
+It seems a good trade-off between traceablity and circuit building overhead.)
+
+For each epoch, the Tp-context SHOULD be refreshed, which includes
+
+* libp2p peer-ID
+* Tp-peer list
+* connections to Tp-peers
+
+Both Tp-peer selection for the next epoch and establishing connections to the newly selected peers SHOULD be done during the current epoch
+and be completed before the new epoch starts.
+This avoids adding latency to message transmission.
+
+# Security/Privacy Considerations
+
+## Fingerprinting Attacks
+
+Protocols that feature distinct patterns are prone to fingerprinting attacks when using them over Tor Push.
+Both malicious guards and exit nodes could detect these patterns
+and link the sender and receiver, respectively, to transmitted traffic.
+As a mitigation, such protocols can introduce dummy messages and/or padding to hide patterns.
+
+## DoS
+
+### General DoS against Tor
+
+Using untargeted DoS to prevent Tor Push messages from entering the gossipsub network would cost vast resources,
+because Tor Push transmits messages over several circuits and the Tor network is well established.
+
+### Targeting the Guard
+
+Denying the service of a specific guard node blocks Tp-nodes using the respective guard.
+Tor guard selection will replace this guard [TODO elaborate].
+Still, messages might be delayed during this window which might be critical to certain applications.
+
+### Targeting the Gossipsub Network
+
+Without sophisticated rate limiting (for example using [17/WAKU2-RLN-RELAY](/spec/17)),
+attackers can spam the gossipsub network.
+It is not enough to just block peers that send too many messages,
+because these messages might actually come from a Tor exit node that many honest Tp-nodes use.
+Without Tor Push, protocols on top of gossipsub could block peers if they exceed a certain message rate.
+With Tor Push, this would allow the reputation-based DoS attack described in
+[Bitcoin over Tor isn't a Good Idea](https://ieeexplore.ieee.org/abstract/document/7163022).
+
+### Peer Discovery
+
+The discovery mechanism could be abused to link requesting nodes to their Tor connections to discovered nodes.
+An attacker that controls both the node that responds to a discovery query,
+and the node who’s ENR the response contains,
+can link the requester to a Tor connection that is expected to be opened to the node represented by the returned ENR soon after.
+
+Further, the discovery mechanism (e.g. discv5) could be abused to distribute disproportionately many malicious nodes.
+For instance if p% of the nodes in the network are malicious,
+an attacker could manipulate the discovery to return malicious nodes with 2p% probability.
+The discovery mechanism needs to be resilient against this attack.
+
+## Roll-out Phase
+
+During the roll-out phase of Tor Push, during which only a few nodes use Tor Push,
+attackers can narrow down the senders of Tor messages to the set of gossipsub nodes that do not originate messages.
+Nodes who want anonymity guarantees even during the roll-out phase can use separate network interfaces for their default context and Tp-context, respectively.
+For the best protection, these contexts should run on separate physical machines.
+
+# Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+# References
+
+* [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
+* [libp2p pubsub](https://github.com/libp2p/specs/tree/master/pubsub)
+* [libp2p pubsub message](https://github.com/libp2p/specs/tree/master/pubsub#the-message)
+* [libp2p switch](https://docs.libp2p.io/concepts/multiplex/switch)
+* [SOCKS5](https://www.rfc-editor.org/rfc/rfc1928)
+* [Tor](https://www.torproject.org/)
+* [33/WAKU2-DISCV5](/spec/33/)
+* [Bitcoin over Tor isn't a Good Idea](https://ieeexplore.ieee.org/abstract/document/7163022)
+* [17/WAKU2-RLN-RELAY](/spec/17)
+
+
+

content/docs/rfcs/47/README.md

@@ -0,0 +1,49 @@
+---
+slug: 47
+title: 47/WAKU2-TOR-PUSH
+name: Waku v2 Tor Push
+status: raw
+category: Best Current Practice
+tags:
+editor: Daniel Kaiser <danielkaiser@status.im>
+contributors:
+---
+
+
+# Abstract
+
+This document extends the [11/WAKU2-RELAY](/spec/11/), specifying Waku Tor Push,
+which allows nodes to push messages via Tor into the Waku relay network.
+
+Waku Tor Push builds on [46/GOSSIPSUB-TOR-PUSH](/spec/46).
+
+**Protocol identifier**: /vac/waku/relay/2.0.0
+
+Note: Waku Tor Push does not have a dedicated protocol identifier.
+It uses the same identifier as Waku relay.
+This allows Waku relay nodes that are oblivious to Tor Push to process messages received via Tor Push.
+
+
+# Functional Operation
+
+In its current version, Waku Tor Push corresponds to [46/GOSSIPSUB-TOR-PUSH](/spec/46)
+applied to [11/WAKU2-RELAY](/spec/11/),
+instead of [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md).
+
+# Security/Privacy Considerations
+
+see [46/GOSSIPSUB-TOR-PUSH](/spec/46)
+
+# Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
+
+# References
+
+* [11/WAKU2-RELAY](/spec/11/)
+* [libp2p gossipsub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/README.md)
+* [46/GOSSIPSUB-TOR-PUSH](/spec/46)
+* [Tor](https://www.torproject.org/)
+
+
+

content/menu/index.md

@@ -15,6 +15,8 @@ bookMenuLevels: 1
   - [43/WAKU2-NOISE-PAIRING]({{< relref "/docs/rfcs/43/README.md" >}})
   - [44/WAKU2-DANDELION]({{< relref "/docs/rfcs/44/README.md" >}})
   - [45/WAKU2-ADVERSARIAL-MODELS]({{< relref "/docs/rfcs/45/README.md" >}})
+  - [46/GOSSIPSUB-TOR-PUSH]({{< relref "/docs/rfcs/46/README.md" >}})
+  - [47/WAKU2-TOR-PUSH]({{< relref "/docs/rfcs/47/README.md" >}})
 - Draft
   - [1/COSS]({{< relref "/docs/rfcs/1/README.md" >}})
   - [3/REMOTE-LOG]({{< relref "/docs/rfcs/3/README.md" >}})