First off, big thanks to @fryorcraken, @prem, and @haelius for the incredibly detailed and thoughtful feedback on the Mix Protocol RFC.
General Clarification on the Spec
The current spec is somewhat outdated. As @prem mentioned, we have shifted from the initial protocol-based approach to a transport-based approach due to challenges outlined in the README.md here. Even in the protocol-based approach described in the spec, certain aspects could be clarified further.
For example, the spec already states:
The Mix protocol is designed with flexibility in mind, allowing for pluggable components such as spam protection, peer discovery, and incentivization mechanisms. This design choice enables the protocol to evolve and adapt to different network requirements and constraints. This also leaves room for future enhancements such as cover traffic generation.
However, this flexibility is not consistently emphasized throughout the document. Components like discovery mechanisms (e.g., discv5) and spam protection (e.g., PoW) are presented as examples but are not mandatory. These examples were intended for clarity but may have inadvertently complicated the spec. In future updates, we plan to simplify this by removing these examples or explicitly marking them as optional.
The reason for including discv5 as an example was to ensure that mix nodes are chosen randomly. Any discovery mechanism that provides a random sample of nodes from the entire network (without skew) can be used.
Why Not a Tor-like Approach
Initially, we explored a Tor-like approach (Tor Push). However, it is known to be vulnerable to traffic correlation attacks in two main ways:
- Traffic volume analysis: An attacker observing both ends of a Tor circuit can correlate the volume and timing of data to deanonymize users.
- Probing attacks: Active adversaries can inject traffic patterns and observe their propagation through the network.
By switching to Sphinx cryptographic format and implementing a mix network approach, we aim to achieve better anonymity protection against these types of attacks, albeit at some cost to performance. Our design decisions prioritize stronger metadata protection. It’s important to note that both systems have their strengths and are designed for different purposes.
One thing to keep in mind is that for complex use cases (e.g., GossipSub), only the first hop may need to be anonymized rather than all the hops. This would reduce overall latency. Additionally, we can send messages over 3-4 redundant paths to improve reliability without significantly increasing the deanonymization probability.
Responses to Specific Comments
(1) Multiple Keys in ENRs
This is a valid concern. Currently, ENRs include both secp256k1 (for ENR signatures and libp2p authentication) and ed25519 (for Sphinx encryption). While having separate keys for signing and encryption is generally a good practice for security separation, ENR size constraints are indeed a challenge. As this is a bottleneck, we should explore ways to consolidate or optimize key usage without compromising security.
(2), (3), and (4) Supported Protocols in ENRs
Mix transport does not use multistream negotiation like traditional libp2p transports. Therefore, the sender must know beforehand whether the destination supports a specific protocol. This can be advertised in a space-efficient manner within ENRs or another metadata mechanism. We agree that the current approach could be optimized further.
(5) Path Length Variable
As @prem mentioned, L refers to the path length. This omission in the earlier part of the spec is an oversight.
6) Mid-Transmission Discovery
In our current PoC implementation, we encode the full multiaddress including peerID (or the mixID) in the Sphinx packet. This eliminates the need for mid-transmission discovery. The format used is:
/ip4/<ip4>/tcp/<port>/mix/<id>
as @haelius mentioned.
(7) Redundancy in Circuits
Since discovery is not required mid-transmission in our current implementation, redundancy at intermediary nodes is unnecessary.
(8) Random Node Selection Without Replacement
To mitigate traffic correlation attacks, nodes in a path must be chosen randomly without repetition. This ensures stronger anonymity properties by preventing any single node from observing multiple points in a path.
(9) and (10) Transport Protocol Flexibility
The choice of transport protocol (TCP, QUIC, etc.) is left to the consumer for flexibility. In our PoC implementation, we use TCP but aim to support both TCP and QUIC in future iterations.
(11) Spam Protection
Spam protection is intentionally designed as a pluggable component and has been moved to an appendix in the current spec for clarity. To avoid confusion, we may completely omit it from future versions of the spec or explicitly note that it is optional.
(12) Preventing Abuse of Mixnets
Spam protection mechanisms like PoW are included to prevent abuse of mixnets by malicious users opening excessive connections to destinations. While this does not directly protect intermediary nodes from DoS attacks, it helps mitigate abuse when anonymizing connections to, for example, a light push peer.
(13) RFC Formatting Issues
We will review and address formatting issues in future updates to ensure better readability.
For further clarity on any unaddressed points, 'll follow up with detailed discussions in subsequent communications.
