Tor Stream Isolation

[JeremyRand]

namecoind RPC commands which reveal private information to the network (e.g. broadcasting transactions, or asking for transactions via SPV) should accept an "identity" parameter. New identity parameter values would result in using a different set of peer nodes, with different SOCKS authentication values (if SOCKS is in use).

This is also relevant to Bitcoin, but affects us more once we start allowing SPV lookups of name data. So if we develop this feature, we should try to get it merged upstream to Bitcoin.

This was discussed at the 2014 01 03 #namecoin-dev meeting.

Placing this ticket in meta because Namecore isn't in the namecoin account yet; it should be moved to the Namecore repo once it's in the namecoin account.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/7482645-tor-stream-isolation?utm_campaign=plugin&utm_content=tracker%2F6562918&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F6562918&utm_medium=issues&utm_source=github).

[JeremyRand]

We're now at the point where this actually matters. I have SPV name lookups working (merged to libdohj yesterday), and it would be great to have stream isolation support.

So, I suggest modifying the syntax of name_show accordingly. A new optional argument is added to name_show, called stream_identity. It is recommended that the passed value of stream_identity be unique for a given stream isolation setting for Tor. This means that, in the example of Tor Browser streams, it should be derived from the client IP, SOCKS username, SOCKS password, SOCKS IP, and SOCKS port. Deciding what data to base this on is application-dependent and should be done with care.

The following existing call:

name_show d/domob

Shall be defined to return an error if performing the lookup will reveal information to a remote third party about what name is being looked up. For a full node implementation like Namecoin Core, such an error will never occur.

The new call:

name_show d/domob www.domob.bit

Shall be defined to perform a name_show lookup that is stream-isolated from all lookups with a stream_identity that is not www.domob.bit. This means, among other things:

1. www.domob.bit is passed as a SOCKS authentication string to any Tor client that might be used for the lookup
2. Any TCP stream used to contact an API server must be unique to this stream_identity.
3. Any Namecoin peer group used for this lookup must be unique to this stream_identity.

Any application, such as ncdns, which is unable to provide meaningful stream_identity data ("meaningful" means the kind of data that TorBrowser would provide via SOCKS authentication) may pass a constant dummy stream_identity as long as the end user has been informed of the privacy risks and has explicitly consented to this. It is notable that a locally running Unbound instance is unlikely to be capable of providing stream_identity; this means that if an SPV remote lookup client is installed as part of a system-wide DNS resolver, the user must be informed of the privacy risks and must explicitly consent.

@domob1812 @hlandau : Your opinions are particularly valuable here since this affects Namecoin Core and ncdns. Feedback welcome from anyone else too.

[domob1812]

I'm a bit hesitant here. As you say, this issue is non-existant for Namecoin Core - hence adding an argument that is then simply ignored seems a bit strange. But I agree that we should strive for fully compatible name_show calls for full nodes vs SPV clients and have no strong objections against adding an ignored argument for this reason.

However, why can't SPV nodes simply use a new Tor circuit for every request (or do it per name) automatically? There's no harm in that, even if it would not be necessary for some cases. The only drawback I see here is that this provides no way for non-Tor-supporting clients to fail when a Tor identity is requested; but I don't think that's an issue - a user who installs a client that does not support Tor should not expect to get Tor anonymity. (We should warn about SPV clients that do this, of course, but even an explicit stream identifier would not prevent a poorly designed client from just ignoring it when not requesting over Tor.)

What do I miss here?

[JeremyRand]

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 07/06/2016 11:22 AM, Daniel Kraft wrote:

I'm a bit hesitant here. As you say, this issue is non-existant for Namecoin Core - hence adding an argument that is then simply ignored seems a bit strange. But I agree that we should strive for fully compatible |name_show| calls for full nodes vs SPV clients and have no strong objections against adding an ignored argument for this reason.

However, why can't SPV nodes simply use a new Tor circuit for every request (or do it per name) automatically? There's no harm in that, even if it would not be necessary for some cases. The only drawback I see here is that this provides no way for non-Tor-supporting clients to fail when a Tor identity is requested; but I don't think that's an issue - a user who installs a client that does not support Tor should not expect to get Tor anonymity. (We should warn about SPV clients that do this, of course, but even an explicit stream identifier would not prevent a poorly designed client from just ignoring it when not requesting over Tor.)

What do I miss here?

Stream isolation may apply to non-Tor lookups. For example, using a unique peer group on the P2P network might be sufficient for some threat models even if Tor is not in use.

As the proposal says, in a case where a client can't support stream isolation, as long as it gets consent from the user, it's fine. (For example, it shows a warning dialog when installing, which explains the privacy risk, and makes the user type "I agree".)

Using a new Tor circuit per lookup would be unusably slow and DoS the Tor network, because Tor circuits take both a lot of time and a lot of CPU resources to build (on the part of relays as well as the client). That's why Tor doesn't use a new circuit per stream.

Isolating by lookup name would be a privacy leak. For full details, see the Tor Browser design docs, but consider the following scenario: 2 different websites both embed a 1px*1px transparent image from different subdomains of the same d/ name. The user visits both of the sites. If lookup name is used as the stream isolation mechanism, the two subdomains are retrieved using the same Tor circuit, which means the owner of that d/ name knows that the visits to both websites came from the same user. This is why Tor Browser uses the domain in the URL bar as the stream isolation mechanism, not the destination domain of the specific stream being loaded. Additionally, for some use cases, it makes sense to isolate different streams going to the same URL bar -- if you have multiple email accounts at the same provider, you may not want the provider to know that they belong to the same person. (Similar logic may apply to RSS feeds on a Bitcoin block explorer, etc.)

(Yes, anonymity is a complicated topic. :) ) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2

iQIcBAEBCAAGBQJXfUoCAAoJEAHN/EbZ1y068xcQANgwT09CGAq35qs0keptwrFc GeLxUEqk3iV4WEpk/M8s/ZmoIExbjVRZFfsdePYc1CY/pzXxydVP+96QTIiiI1rT 4X/3Q1Uc4OmEsW3cnruRDXz2cu500JTb+L/z9ans/ukar1nbaHQjZDeLdFRBPbNm Ltw8h/9kilf2MMev/GPRgMhezZHBUHu9ApgiA8r70oLgHHjDgro4NuGQICDbqiwT qDGqsgAqBWXf/B3klNMv7lBPjqwga01jyhx/KpruuYdHmCMIB6uGTN7TfbyIDgoN LozNzdwB8m5gCQasHEAzmn1WAAPUQcaL8sHkqum+z+nH7/Kntepzhez8es/OSZiV VUHJpl3FfkYnWjz2ZmV6QWY51iJA5yap9Eapa9J9wXRlF2aqYFGPwkb55fwh04UC q0pFwx2uSQyoXQ5Bp3+mkT8axZL1KKyfLK36w2kx4wsfKwXPHEtCjtfBkar7c4Ug 9m5QWNfoFqEk4aTquGZ96Izk/NTbLvBAoFJCndiAC7vnwCIgaSb+SCAS3Qv4E3oo 8AGS1FX+Z4Yxjy8hSU+JHhNGyy4pCfN56WkbL9mBVCk7oaEEIFkRZWde5KzvR+Ii LbBhOqcvfYGFzWITFbKKkN0DTXhJdgEmso7pzoi3YHxTV5IwPQmedab6Bw6SziuD RozDCllxXU3xjoLGwMn8 =0pq7 -----END PGP SIGNATURE-----