if application or upper-protocol layer uses its own encryption which most of them do, exit node would not have complete visibility rather only the protocol and destination information of the packet.

maybe better to mention this

You’re right that in most real deployments, the application payload inside the Sphinx packet may itself be encrypted.
What we’re describing here is the trust boundary at the Mix Protocol layer, where Mix-layer encryption is fully removed.
We compare this to other mixnet designs and to Tor with unencrypted traffic, and explain that this is typically addressed with end-to-end encryption, which is harder in Mix due to its stateless, message-based nature.

endpoints should still be able to establish session keys if they want since sender is aware of destination ID, just that key exchange messages would also flow through different exit nodes. or am i missing something?

Establishing a session key usually requires correlating multi-round handshakes across different paths and exits as part of the same session, which isn't currently feasible in the Mix Protocol's stateless, unlinkable model (especially with exit ≠ destination). Each message is routed independently and there’s no persistent session identifier across messages.

Establishing a session key usually requires correlating multi-round handshakes across different paths and exits as part of the same session, which isn't currently feasible in the Mix Protocol's stateless, unlinkable model (especially with exit ≠ destination). Each message is routed independently and there’s no persistent session identifier across messages.

Can endpoints establish session in below way?

NodeA -> (mixnet)-> NodeB (session initiate) (Req1)
NodeB -> (mixnet) -> NodeB (init ack). (SURB)
NodeA -> (mixnet) -> NodeB (session msg1) (Req2)
....
NodeB -> (mixnet )-> NodeA (end session setup msg) (SURB n)

Wouldn't the above be possible with req and SURB even if different exit nodes are used and different paths are taken for each message?
Also i am looking at session establishment as a user layer mechanism agnostic to mix layer. Maybe we both are talking about 2 different types of session establishment.

This can be mitigated by having other mechanisms in place e.g waku has RLN that rate limits publishers from publishing too many messages and this requires that publisher provide a proof of membership which the exit node would not be able to do if it doesn't have one.

Similarly waku also implementes various per peer rate limiting scehemes to ensure that nodes don't just keep opening connections and start misusing the protocol.

Maybe worthwhile to mention that mechanisms as such can be used to mitigate this abuse.

RLN and similar rate-limiting mechanisms do not mitigate the specific form of abuse discussed here.
The Mix Exit Layer initiates a client-side connection to the destination’s origin protocol instance (e.g., Waku). However, the exit is not required to support Waku, i.e., it is not a verifiable peer with long-term identity. As a result, these protocol-level safeguards (that rely on long-term identity and membership proofs), do not apply to these transient client connections.
A malicious exit could repeatedly reconnect, send semantically valid but fabricated messages, and bypass such protections entirely.

As a result, these protocol-level safeguards (that rely on long-term identity and membership proofs), do not apply to these transient client connections.

Understood, but these are not protocol specific safegaurds, rather depends on initiator identtity in various forms.

e.g lightpush service node would have per peer rate-limits (i.e based on libp2p peerID) and as exit node has libp2p peerID, rate limit would still apply. But now this leads me to a new question i.e when using mix even if actual initiator(nodeA) has not exhausted rate limit, just because the exit node chosen has already been chosen by many other clients and nodeA's request may get rate limited.

This problem may get mitigated by using exit==destination though. cc @jm-clius another minor reason to prefer exit ==destination model for waku req-resp protocols.

A malicious exit could repeatedly reconnect, send semantically valid but fabricated messages, and bypass such protections entirely.

Based on above explanation, i doubt this would happen in case of Waku protocols.

Wouldn't this reduce the anonymity set and open a scenario where people monitoring network traffic would be able to do corelation and timing analysis?