feature: error messaging/reporting in SURB replies

[chaitanyaprem]

I was thinking about SURB's while integrating with Waku and realized something that i confirmed after looking into the code.

As of now if a reply is larger than payloadSize supported ( in case of store protocol the sender is not aware of the size of reply) reply gets dropped silently and sender will keep retying thinking there is a network issue or path broken etc.

Since exit layer detects this error and it has SURB, it makes sense to send back the error to the sender so that entry_layer can then identify and report it back to sender protocol. This is just 1 error that i thought of, but i am sure other errors like this exist which need reporting to sender so that sender can take action accordingly.

This would happen since destination node protocol is not aware that this packet came via mix and hence not aware of possible size limitations.

There is a need to identify any other such errors that can be relayed back to sender via SURB and perform similar action.

@AkshayaMani WDYT?

[AkshayaMani]

Thanks for raising this! It's a great point and one we discussed during the SURB design phase (cc @richard-ramos ).

The key challenge is that the SURB key k, used to encrypt the response, should ideally be known only to the endpoints (sender and destination). However, in the exit ≠ destination model, the exit holds this key and is trusted to forward a response from the destination, but not to originate one. Allowing it to do so — even for error reporting — expands the exit’s role and breaks the sender’s trust model.

Of course, this reflects a broader limitation of the exit ≠ destination design: since the exit sees the plaintext and holds the key for encrypting the response, it becomes a privileged middleman that could forge onward messages (and responses) indistinguishable from those from the correct source. This limitation is documented in the RFC under the Security Considerations section (WiP) and is consistent with similar trust boundaries in many mixnet designs.

So for now, the design avoids having the exit send anything back in case of an error. While this means the sender can't distinguish between a path-level failure and an application-layer errors, it preserves response integrity.

In contrast, in the exit == destination setup, the destination could probably trust the local Mix instance to send back an error reply directly using the SURB. Even then, we recommend applications handle error detection, passing structured errors to the local Mix instance, which can then route them back via the SURB.

[chaitanyaprem]

Of course, this reflects a broader limitation of the exit ≠ destination design: since the exit sees the plaintext and holds the key for encrypting the response, it becomes a privileged middleman that could forge onward messages (and responses) indistinguishable from those from the correct source. This limitation is documented in the RFC under the Security Considerations section (WiP) and is consistent with similar trust boundaries in many mixnet designs.

Agreed, Looks like exit == destination design seems to have better security properties in general.
cc @jm-clius

In Waku since we are planning to move to exit == destination approach this kind of error handling atleast from exit node would help in protocols like Waku-Store where sender doesn't know the response size and would be aware of the error atleast rather than just keep retrying.