Re-wrapping of forwarded messages should be mandatory

When a mediator receives a Forward message, the payload is untrusted and (likely) unvalidated. It may not even be a DIDComm message. If the mediator blindly forwards this payload to its target recipient, it is providing an almost direct channel to whatever transport protocol the target is using. This might be used, for example, to deliver a payload crafted to exploit a known security issue in the client's transport implementation. Re-wrapping the message eliminates this exposure, transmitting the payload in a relatively safe container where a class of undesired effects are avoided.

Another unwanted aspect of delivering unwrapped message payloads is that the behaviour of envelope headers may refer to aspects of the message transport – in this case, the transport between the mediator and the next recipient. How should a client behave when a forwarded message uses the return-route extension to indicate a direct response? If the payload is re-wrapped, then the context of the extension is clear, and in this case it must be ignored. If not, then the response may be sent naively to the mediator agent, likely being dropped because it refers to another recipient. Depending on what headers are supported in future, there could be other security implications.

Re-wrapping may also be useful for preventing abuse, in the case where a recipient wishes to block incoming messages from a particular sender. This might require the mediator to include provenance information in the forward message, such as the originating IP address. Alternatively, the ID of the forwarding wrapper might be used quickly report undesired forwards and invoke some spam prevention mechanism at the mediator. If the raw payload is delivered, then neither of these options is available.

A client and mediator could choose to opt-out of the re-wrapping operation if they are closely associated, perhaps for performance reasons, but this behaviour should be considered non-conforming.