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

[Mike Perry]

It's me again. It looks like I'm still the Internet champion of
"Thinking once and posting twice".

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).

This paragraph is wrong. Of course, the adversary can just poll the
hsdir themselves actively to learn the current into points. It's still
O((c/n)^2). Embarrassing.

> 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.

I think my traffic analysis concerns still stand, though. I'm especially
nervous about having the IP lifetimes fixed at the same lifespan as the
hsdirs. It would be better if we're able to shorten those as we better
understand the benefits of padding and the risks of traffic analysis
here.

One option might be leaving Prop 246 as an optional later optimization.
If we don't change the 224 crypto at all to optimize it for 246, we can
still save the same number of network round trips if clients know to
re-use their hsdir circ to perform the intro request if one of the
listed intro points happens to be the current hsdir. That way we save
the same number of round trips if we want, but don't lock ourselves in
to this path restriction and associated circuit lifespan issue? Sure,
we'd be doing a little bit of needless crypto, but the important thing
is we can still save the network round trips and circuit construction.


-- 
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/e40c02d7/attachment.sig>