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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev