[tor-dev] Revisiting Proposal 246: Merging Hidden Service Directories and Introduction Points

[Mike Perry]

George Kadianakis:
> Hello there,
> 
> we recently finished implementing proposal 250 which is one of the first steps
> for the upcoming hidden service redesign [1]. The next steps are implementing
> proposal 224 and the other performance and security proposals [2].
> 
> On this note, one of the open design issues that we need to tackle next is
> whether we should do proposal 246 or not. Proposal 246 merges HSDirs and Intro
> Points into a single entity to simplify the protocol and improve its
> performance. The idea is that HSes will pick their intro points using the hash
> ring algorithm currently used for picking HSDirs. Clients will do the same and
> connect directly to the intro points instead of going through the HSDir step.
> 
> I suggest you read the proposal and the discussion thread to become better
> informed about this idea:
>  https://lists.torproject.org/pipermail/tor-dev/2015-July/009079.html
> 
> Proposal 246 changes the hidden service protocol substantially, which is why we
> need to decide whether to do it soon. The next steps in our implementation plan
> heavily depend on whether we will do proposal 246 or not.
> 
> Here are some issues that make this proposal not an obvious pick:
> 
> 1) Security issues
> 
>    - Professor Hopper pointed out [3] that this proposal will double the number
>      of introduction points of a hidden service (from the current 3 to 6).
>      Introduction points have slightly more attack vectors than HSDirs, so we
>      should not increase their number without analyzing further.

An additional related security issue is the traffic analysis benefits of
separating out hsdir, IP, and RP. Recall that the original onion routing
design did this on purpose (despite considerable performance drawback),
so that actual circuit-level traffic patterns from the hidden service
would be fully decoupled from their identity information.

If we were to merge hsdirs with intro points that have long-lived
circuits opened to them, we create additional point where an adversary
who sees/learns/knows the hs address can attempt to passively or
actively correlate traffic patterns with a malicious hidden service
guard. There will be much more traffic available at the intropoint for
such passive or active traffic analysis than there will be during a
simple hsdir fetch or post, which means that long-term traffic analysis
and related intersection/statistical disclosure attacks have much more
opportunity to succeed. Long-term traffic analysis is also much harder
to combat with padding.

Granted, even with prop 224, an adversary that knows a non-authenticated
hidden service address can decrypt the descriptor to learn the
introduction points, but to actually be in the position to perform
circuit-level traffic analysis on them requires another c/n multiplier,
making the full attack succeed with probability O((c/n)^3) (ie, the
adversary has to get in the guard, hsdir, and intropoint positions to be
fully successful).

I think this is reason enough to reject Proposal 246 for high security
onion services by itself, but the complications with onionbalance also
concern me, as well.


-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160115/2402c8c5/attachment.sig>