Clearing the state of rendezvous client provides privacy improvement?

Question

Context. In my quest on figuring out if I must use NEWNYM signal or stream isolation is enough for me I dig into the code and narrowed down the possible privacy improvements that NEWNYM can bring over simple stream isolation, so I can ask more specific questions. One of it is clearing the state of rendezvous client.

Goal. My goal is to be able to talk with a server with two different identity, without the server, learning let's say Alice and Bob are the same user. Where the server is a hidden service.

What I know. This answer explains one thing that Tor does for NEWNYM request:

src/or/rendclient.c:rend_client_purge_state clears the state of the rendezvous client (hidden services) to avoid possible links between the old and new nym because of the new nym starting with the end state of the old nym.

Question. Is there a risk the server can learn the connection between Alice and Bob without clearing the state of the rendezvous client? If so, then how much of this risk is?

For reference I also drop the code here, its comments may be useful:

/** Purge all potentially remotely-detectable state held in the hidden
 * service client code.  Called on SIGNAL NEWNYM. */
void
rend_client_purge_state(void)
{
  rend_cache_purge();
  rend_cache_failure_purge();
  rend_client_cancel_descriptor_fetches();
  rend_client_purge_last_hid_serv_requests();
}

rend_cache_purge

/** Remove ALL entries from the rendezvous service descriptor cache.
*/
void
rend_cache_purge(void)
{
  ...
}

rend_cache_failure_purge

/** Remove ALL entries from the failure cache. This is also called when a
 * NEWNYM signal is received. */
void
rend_cache_failure_purge(void)
{
  ...
}

rend_client_cancel_descriptor_fetches

/** Cancel all rendezvous descriptor fetches currently in progress.
 */
void
rend_client_cancel_descriptor_fetches(void)
{
  ...
}

rend_client_purge_last_hid_serv_requests

/** Purge the history of request times to hidden service directories,
 * so that future lookups of an HS descriptor will not fail because we
 * accessed all of the HSDir relays responsible for the descriptor
 * recently. */
void
rend_client_purge_last_hid_serv_requests(void)
{
  ...
}

Answer 1

Is there a risk the server can learn the connection between Alice and Bob without clearing the state of the rendezvous client? If so, then how much of this risk is?

Yes. It could be possible for an onion service to create an oracle that would allow it to link Alice and Bob if they're simply using Stream Isolation copared to if their connections were re-made after a NEWNYM signal was sent.

It's potentially a little far fetched, but it is possible. They likely wouldn't notice it incidentally but they could try to set a trap to catch you out.

One example might be:

1. The malicious service publishes a set of descriptors for its onion service to its HSDirs, advertising one or more introduction points.
2. The user fetches the descriptors to talk to the service and establishes a rendezvous connection on an isolated circuit.
3. The service generates a new set of descriptors with a new set of introduction points and publishes them to the HSDirs.
4. The user performs actions on the onion service as Alice and disconnects.
5. The user uses stream isolation to create a new circuit to the service but because they did not clear the rendezvous cache they use the old introduction point from the old descriptor.
6. The user performs actions on the onion service as Bob and disconnects.
7. The malicious onion service can reason (within some range of probability, increasing over time) that Alice and Bob are, at least, using the same Tor instance.

Another example:

1. The malicious service ensures that one of it's HSDirs is under its control, and publishes its descriptors exclusively to this HSDir.
2. The user fetches the HS descriptor for the malicious services HSDir, and establishes a rendezvous circuit.
3. The user performs actions on the service as Alice.
4. The user disconnects, and establishes a new circuit with stream isolation.
5. The user performs actions on the service as Bob.
6. The malicious service notes that Bob did not fetch its descriptor, and must have already known it.

This second attack won't be feasible with v3 onions, it could also be combined with the first attack to serve users specific, poisoned descriptors to make it more effective.

In summary: If you want a new identity, you need to use NEWNYM (as well as ensuring you clear state from the client application, e.g. with New Identity on Tor Browser). Anything else will likely be insufficient, that is why it is there.