RFC Addition: Section 9 Security Considerations (#194)

This PR continues work from PR #158 and PR #173, and introduces a new
**Section 9: Security Considerations** to the Mix Protocol RFC. It
formalizes the protocol’s core guarantees, trust assumptions, and known
limitations.

### New Section Added

Structured Section 9 with the following subsections:

- [x] **9.1 Security Guarantees of the Core Mix Protocol**
Defines sender anonymity, metadata protection, and statelessness
guarantees.

- [x] **9.2 Exit Node Trust Model**
  Trust assumptions at the final hop:

  - [x] `9.2.1 Message Delivery and Origin Trust`
  - [x] `9.2.2 Origin Protocol Trust and Client Role Abuse`

- [x] **9.3 Destination as Final Hop**
Optional deployment model where the destination operates its own Mix
instance to eliminate exit-level trust.

- [x] **9.4 Known Protocol Limitations**
  Clearly outlines out-of-scope threats:
  - Undetectable node misbehavior
  - Lack of built-in retries or acknowledgments
  - No Sybil resistance
  - Vulnerability to DoS attacks

### Key Improvements
- Clearly delineates what the Mix Protocol guarantees and what it leaves
to external systems.
- Formalizes the exit trust boundary, a key concept for downstream
applications.
- Introduces an alternative destination participation model.
- Enables future discussions around accountability, reliability, and
Sybil resistance.

---------

Co-authored-by: Prem Chaitanya Prathi <chaitanyaprem@gmail.com>

vac/raw/mix.md

@@ -1751,3 +1751,257 @@ steps to interpret routing block $B$ and decrypted payload $δ'$ obtained in
    forwarding the message to the destination. Implementations MAY reuse an
    existing stream to the destination, if doing so does not introduce any
    observable linkability between forwarded messages.
+
+## 9. Security Considerations
+
+This section describes the security guarantees and limitations of the Mix
+Protocol. It begins by outlining the anonymity properties provided by the core
+protocol when routing messages through the mix network. It then discusses the
+trust assumptions required at the edges of the network, particularly at the
+final hop. Finally, it presents an alternative trust model for destinations
+that support Mix Protocol directly, followed by a summary of broader
+limitations and areas that may be addressed in future iterations.
+
+### 9.1 Security Guarantees of the Core Mix Protocol
+
+The core Mix Protocol—comprising anonymous routing through a sequence of
+mix nodes using Sphinx packets—provides the following security guarantees:
+
+- **Sender anonymity**: Each message is wrapped in layered encryption and
+  routed independently, making it unlinkable to the sender even if multiple
+  mix nodes are colluding.
+- **Metadata protection**: All messages are fixed in size and indistinguishable
+  on the wire. Sphinx packets reveal only the immediate next hop and delay to
+  each mix node. No intermediate node learns its position in the path or the
+  total pathlength.
+- **Traffic analysis resistance**: Continuous-time mixing with randomized
+  per-hop delays reduces the risk of timing correlation and input-output
+  linkage.
+- **Per-hop confidentiality and integrity**: Each hop decrypts only its
+  assigned layer of the Sphinx packet and verifies header integrity via a
+  per-hop MAC.
+- **No long-term state**: All routing is stateless. Mix nodes do not maintain
+  per-message metadata, reducing the surface for correlation attacks.
+
+These guarantees hold only within the boundaries of the Mix Protocol.
+Additional trust assumptions are introduced at the edges, particularly at the
+final hop, where the decrypted message is handed off to the Mix Exit Layer for
+delivery to the destination outside the mixnet. The next subsection discusses
+these trust assumptions in detail.
+
+### 9.2 Exit Node Trust Model
+
+The Mix Protocol ensures strong sender anonymity and metadata protection
+between the Mix Entry and Exit layers. However, once a Sphinx packet is
+decrypted at the final hop, additional trust assumptions are introduced.
+The node processing the final layer of encryption is trusted to forward the
+correct message to the destination and return any reply using the provided
+reply key. This section outlines the resulting trust boundaries.
+
+#### 9.2.1 Message Delivery and Origin Trust
+
+At the final hop, the decrypted Sphinx packet reveals the plaintext message
+and destination address. The exit node is then trusted to deliver this message
+to the destination application, and—if a reply is expected—
+to return the response using the embedded reply key.
+
+In this model, the exit node becomes a privileged middleman. It has full
+visibility into the decrypted payload. Specifically, the exit node could tamper
+with either direction of communication without detection:
+
+- It may alter or drop the forwarded message.
+- It may fabricate a reply instead of forwarding the actual response from the
+  destination.
+
+This limitation is consistent with the broader mixnet trust model. While
+intermediate nodes are constrained by layered encryption, edge nodes
+—specifically the initiating and the exit nodes in the path—
+are inherently more privileged and operate outside the cryptographic protections
+of the mixnet.
+
+In systems like Tor, such exit-level tampering is mitigated by long-lived circuits
+that allow endpoints to negotiate shared session keys (_e.g.,_ via TLS). A
+malicious exit cannot forge a valid forward message or response without access to
+these session secrets.
+
+The Mix Protocol, by contrast, is stateless and message-based. Each message is
+routed independently, with no persistent circuit or session context. As a
+result, endpoints cannot correlate messages, establish session keys, or validate
+message origin. That is, the exit remains a necessary point of trust for message
+delivery and response handling.
+
+The next subsection describes a related limitation: the exit’s ability to pose
+as a legitimate client to the destination’s origin protocol, and how that
+can be abused to bypass application-layer expectations.
+
+#### 9.2.2 Origin Protocol Trust and Client Role Abuse
+
+In addition to the message delivery and origin trust assumption, the exit
+node also initiates a client-side connection to the origin protocol instance
+at the destination. From the destination's perspective, this appears
+indistinguishable from a conventional peer connection, and the exit is accepted
+as a legitimate peer.
+
+As a result, any protocol-level safeguards and integrity checks are applied
+to the exit node as well. However, since the exit node is not a verifiable peer
+and may open fresh connections at will, such protections are limited in their
+effectiveness. A malicious exit may repeatedly initiate new connections, send
+well-formed fabricated messages and circumvent any peer scoring mechanisms by
+reconnecting. These messages are indistinguishable from legitimate peer messages
+from the destination’s point of view.
+
+This class of attack is distinct from basic message tampering. Even if the
+message content is well-formed and semantically valid, the exit’s role as an
+unaccountable client allows it to bypass application-level assumptions about
+peer behavior. This results in protocol misuse, targeted disruption, or
+spoofed message injection that the destination cannot attribute.
+
+Despite these limitations, this model is compatible with legacy protocols and
+destinations that do not support the Mix Protocol. It allows applications to
+preserve sender anonymity without requiring any participation from the
+recipient.
+
+However, in scenarios that demand stronger end-to-end guarantees—such as
+verifiable message delivery, origin authentication, or control over
+client access—it may be beneficial for the destination itself to operate
+a Mix instance. This alternative model is described in the next subsection.
+
+### 9.3 Destination as Final Hop
+
+In some deployments, it may be desirable for the destination node to
+participate in the Mix Protocol directly. In this model, the destination
+operates its own Mix instance and is selected as the final node in the mix
+path. The decrypted message is then delivered by the Mix Exit Layer directly to the
+destination's local origin protocol instance, without relying on a separate
+exit node.
+
+From a security standpoint, this model provides end-to-end integrity
+guarantees. It removes the trust assumption on an external exit. The message is
+decrypted and delivered entirely within the destination node, eliminating the
+risk of tampering during the final delivery step. The response, if used, is
+also encrypted and returned by the destination itself, avoiding reliance on a
+third-party node to apply the reply key.
+
+This model also avoids client role abuse. Since the Mix Exit Layer delivers the
+message locally, the destination need not accept arbitrary inbound connections
+from external clients. This removes the risk of an adversarial exit posing as
+a peer and injecting protocol-compliant but unauthorized messages.
+
+This approach does require the destination to support the Mix Protocol.
+However, this requirement can be minimized by supporting a lightweight mode in
+which the destination only sends and receives messages via Mix, without
+participating in message routing for other nodes. This is similar to the model
+adopted by Waku, where edge nodes are not required to relay traffic but still
+interact with the network. In practice, this tradeoff is often acceptable.
+
+The core Mix Protocol does not mandate destination participation. However,
+implementations MAY support this model as an optional mode for use in
+deployments that require stronger end-to-end security guarantees. The discovery
+mechanism MAY include a flag to advertise support for routing versus
+receive-only participation. Additional details on discovery configurations are
+out of scope for this specification.
+
+This trust model is not required for interoperability, but is recommended
+when assessing deployment-specific threat models, especially in protocols that
+require message integrity or authenticated replies.
+
+### 9.4 Known Protocol Limitations
+
+The Mix Protocol provides strong sender anonymity and metadata protection
+guarantees within the mix network. However, it does not address all classes of
+network-level disruption or application-layer abuse. This section outlines
+known limitations that deployments MUST consider when
+evaluating system resilience and reliability.
+
+#### 9.4.1 Undetectable Node Misbehavior
+
+The Mix Protocol in its current version does not include mechanisms to detect
+or attribute misbehavior by mix nodes. Since Sphinx packets are unlinkable and
+routing is stateless, malicious or faulty nodes may delay, drop, or selectively
+forward packets without detection.
+
+This behavior is indistinguishable from benign network failure. There is no
+native support for feedback, acknowledgment, or proof-of-relay. As a result,
+unreliable nodes cannot be penalized or excluded based on observed reliability.
+
+Future versions may explore accountability mechanisms. For now, deployments MAY
+improve robustness by sending each packet along multiple paths as defined in
+[Section X.X], but MUST treat message loss as a possibility.
+
+#### 9.4.2 No Built-in Retry or Acknowledgment
+
+The Mix protocol does not support retransmission, delivery acknowledgments,
+or automated fallback logic. Each message is sent once and routed
+independently through the mixnet. If a message is lost or a node becomes
+unavailable, recovery is the responsibility of the top-level application.
+
+Single-Use Reply Blocks (SURBs) (defined in Section[X.X]) enable destinations to
+send responses back to the sender via a fresh mix path. However, SURBs are
+optional, and their usage for acknowledgments or retries must be coordinated by
+the application.
+
+Applications using the Mix Protocol MUST treat delivery as probabilistic. To
+improve reliability, the sender MAY:
+
+- Use parallel transmission across `D` disjoint paths.
+- Estimate end-to-end delay bounds based on chosen per-hop delays (defined in
+  [Section 6.2](#62-delay-strategy)), and retry using different paths if
+  a response is not received within the expected window.
+
+These strategies MUST be implemented at the origin protocol layer or through
+Mix integration logic and are not enforced by the Mix Protocol itself.
+
+#### 9.4.3 No Sybil Resistance
+
+The Mix Protocol does not include any built-in defenses against Sybil attacks.
+All nodes that support the protocol and are discoverable via peer discovery
+are equally eligible for path selection. An adversary that operates a large
+number of Sybil nodes may be selected into mix paths more often than expected,
+increasing the likelihood of partial or full path compromise.
+
+In the worst case, if an adversary controls a significant fraction of nodes
+(_e.g.,_ one-third of the network), the probability that a given path includes
+only adversarial nodes increases sharply. This raises the risk of
+deanonymization through end-to-end traffic correlation or timing analysis.
+
+Deployments concerned with Sybil resistance MAY implement passive defenses
+such as minimum path length constraints. More advanced mitigations such as
+stake-based participation or resource proofs typically require some form of
+trusted setup or blockchain-based coordination.
+
+Such defenses are out of scope in the current version of the Mix Protocol,
+but are critical to ensuring anonymity at scale and may be explored in future
+iterations.
+
+#### 9.4.4 Vulnerability to Denial-of-Service Attacks
+
+The Mix Protocol does not provide built-in defenses against denial-of-service
+(DoS) attacks targeting mix nodes. A malicious mix node may generate
+a high volume of valid Sphinx packets to exhaust computational, memory, or
+bandwidth resources along random paths through the network.
+
+This risk stems from the protocol’s stateless and sender-anonymous design.
+Mix nodes process each packet independently and cannot distinguish honest users
+from attackers. There is no mechanism to attribute packets, limit per-sender
+usage, or apply network-wide fairness constraints.
+
+Application-level defenses—such as PoW, VDFs, and RLNs (defined in
+[Section 6.3](#63-spam-protection)) to protect destination endpoints—
+do not address abuse _within_ the mixnet. Mix nodes remain vulnerable to
+volumetric attacks even when destinations are protected.
+
+While the Mix Protocol includes safeguards such as layered encryption, per-hop
+integrity checks, and fixed-size headers, these primarily defend against
+tagging attacks and structurally invalid or malformed traffic. The Sphinx packet
+format also enforces a maximum path length $(L \leq r)$, which prevents infinite
+loops or excessively long paths being embedded. However, these protections do not
+prevent adversaries from injecting large volumes of short, well-formed messages to
+exhaust mix node resources.
+
+DoS protection—such as admission control, rate-limiting, or resource-bound
+access—MUST be implemented outside the core protocol. Any such mechanism MUST
+preserve sender unlinkability and SHOULD be evaluated carefully to avoid
+introducing correlation risks.
+
+Defending against large-scale DoS attacks is considered a deployment-level
+responsibility and is out of scope for this specification.