Opened 3 years ago

Last modified 2 years ago

#19859 new enhancement

Expose stream isolation information to controllers

Reported by: nickm Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs tor-control dns isolation needs-spec needs-design term-project
Cc: JeremyRand Actual Points:
Parent ID: Points: 3
Reviewer: Sponsor:


See the discussion on the "How to integrate an external name resolver into Tor" thread on tor-dev; most notably .

Resolvers would like to know the isolation information of incoming streams so they know which streams need to be isolated from which other streams.

Semantically, this is a little tricky. The underlying rule that Tor implements is that each stream has a tuple of attributes (A_1, A_2... A_n), and a bit field (b_1, b_2... b_n). Two streams S_a and S_b may share the same circuit iff, for every i such that the OR of their b_i values is true, they have the same A_i value.

Note that this is not transitive: Stream S_a may be able to share a circuit with S_b or S_c, even if S_b cannot share with S_c. Worse

Should we (1) expose these attribute tuples and bitfields and require controllers to manipulate them correctly? That seems obnoxious and error-prone.

Or should we (2) allow controllers to ask questions like "may stream A share a circuit with stream B?" Or "what streams may A share a circuit with?" This might lead to O(n) queries, and it will still be error-prone because of the non-transitivity issue.

Or would it be better to (3) oversimplify the system above and provide each stream a 'cookie' such that any two streams with the same cookie may definitely share the same circuit? But this is problematic, and will overestimate how much isolation we need.

My current best idea is that (4) we should provide an operation of the form "make stream A have the same isolation properties as stream B". And possibly "make circuit C have isolation properties as if it had been used by stream A". So we don't expose isolation information, we just expose a way to manipulate it.

Or maybe there's a further clever way I'm not even thinking about just now.

Child Tickets

Change History (7)

comment:1 Changed 3 years ago by JeremyRand

Hey Nick,

Indeed, this does seem like a complex problem. For the specific use cases that Namecoin has, my guess is that (4) is probably the simplest and least-error-prone option. However, a concern comes to mind: if a Namecoin lookup is considered to have the same isolation properties as the stream created by the client application that generated the Namecoin lookup, this presumably reveals to someone (who? The exit relay? A Namecoin P2P node? The service being accessed? All of the above?) that the Namecoin lookup and the client application stream are linked.

Is this a problem? If the protocol is HTTP(S), then the accessed service can already tell that it's being looked up using Namecoin by checking the Host header (and if TLS isn't used, then the exit relay can also tell this). If the protocol uses TLS, then the accessed service and the exit relay can tell it's being looked up using Namecoin by checking the SNI header (although SNI could be disabled for some protocols that use TLS, and perhaps a future version of TLS will offer SNI encryption). If it's some other protocol that doesn't have a Host-like header, then I don't see any way that the use of Namecoin is inherently detectable. Since Tor is used for arbitrary TCP traffic, I am hesitant to endorse a solution that unnecessarily reveals to adversaries that Namecoin is in use, particularly since Namecoin usage is rather rare right now and therefore this narrows the anonymity set substantially.

From the point of view of the Namecoin P2P node, looking up a Namecoin name doesn't necessarily reveal everything about how it will be used. For example, it normally doesn't reveal what subdomain is being looked up, nor does it reveal what record types are being looked up (IPv4, IPv6, TorHS, TLSA, SSHFP, etc.). It's not immediately obvious to me how much of this extra data is revealed, and to whom, as a result of the service being accessed over the same circuit, but it makes me uneasy without a clear, convincing argument that it's safe.

So, possible solution: offer an operation of the form "make stream A have the same isolation properties as stream B, except that stream A must also be isolated from stream B".

Is this modification worth it? Would it put much extra load on the Tor network? Are my concerns about revealing extra information to adversaries justified, or am I being overly cautious about something that isn't really a threat?


comment:2 Changed 3 years ago by JeremyRand

Cc: JeremyRand added

comment:3 Changed 3 years ago by dgoulet

Keywords: triage-out-030-201612 added
Milestone: Tor: 0.3.0.x-finalTor: 0.3.1.x-final

Triaged out on December 2016 from 030 to 031.

comment:4 Changed 2 years ago by nickm

Points: 3

comment:5 Changed 2 years ago by nickm

Keywords: triaged-out-20170308 added
Milestone: Tor: 0.3.1.x-finalTor: unspecified

Deferring all 0.3.1 tickets with status == new, owner == nobody, sponsor == nobody, points > 0.5, and priority < high.

I'd still take patches for most of these -- there's just nobody currently lined up to work on them in this timeframe.

comment:6 Changed 2 years ago by dgoulet

Keywords: tor-hs added; hidden-services triage-out-030-201612 removed

comment:7 Changed 2 years ago by nickm

Keywords: tor-control dns isolation needs-spec needs-design term-project added; needs-proposal triaged-out-20170308 removed
Note: See TracTickets for help on using tickets.