Here are my thoughts regarding why merging the Hidden Service directory system and regular directory system is a bad idea.
It would mean each directory server effectively has a list of every hidden service in the network. This may or may not be an issue if the descriptors are encrypted.
Additionally you could clog up the directory servers (potentially causing a DoS situation) by publishing massive quantities of hidden service descriptors. This may already be possible with router descriptors, however, I'm not sure; do directory servers store an arbitrary number of router descriptors from the same IP?
Since directory servers don't tend to change they would appear responsible for each hidden service, opening up the possibility of lawyer attacks => "we demand you stop hosting descriptors for this criminal hidden service", or "you have been aiding criminals by serving this hidden service's descriptors". Also, since they don't change it would be far more worthwhile for an adversary to try to attack or subvert them. The moving-target system that is currently in place is far stronger against these types of attacks.
Lastly since the hidden service will be establishing a circuit to each directory server periodically it may be possible to perform statistical attacks such as a predecessor attack against it. This isn't an issue with router descriptors since the onion routers aren't trying to be anonymous, but it is an issue with hidden service descriptors.
On Sun, Nov 10, 2013 at 9:19 PM, George Kadianakis desnacked@riseup.net wrote:
Nick Mathewson nickm@torproject.org writes:
On Wed, Oct 16, 2013 at 9:18 PM, George Kadianakis desnacked@riseup.net wrote:
Hey Nick,
these are my notes from when I was writing the HS blog post. I updated them a bit with some more stuff.
Might be helpful :)
Hi, George! Here's the list I came up with. Let's try to merge them, assuming I thought of anything you didn't. I'm also thinking of an initial commentary on some of your items below.
"""
SECURITY:
- Ed25519 for all signatures, curve25519 for all handshake stuff.
- Migrate identities to ed25519.
- Enumeration resistance: hsdirs can't list what services they're serving.
- Proper hybrid encryption for INTRODUCE2 cells.
- Improved authorization systems.
- Consider cost/benefit: At descriptor level, at INTRODUCE1, at INTRODUCE2, and RENDEZVOUS.
- Try to support many distinct users by shared secret, by public key, by...?
- Able to keep identity keys offline and generate keys as needed
- Every part should be harder to DOS
- Hard to predict which HSDirs will get used for a service.
- All hybrid encryption done properly.
- Separate guards for hidden service and for client use?
- Make nearly everything less linkable to the other things.
- Possibly, avoid having to store even public key on hidden service.
SCALING:
- Allow a hidden service to be provided from multiple places somehow.
- Obscure number of instances?
- Avoid having a "master" instance without which the others can't function.
- Obscure which instances are up/down?
- Support more introduction points.
GUARDS:
- Not completely related, but we should go over Roger's big laundry list of guard-related changes and actually make sure they happen.
PLUMBING:
- ntor handshake in place of TAP handshake. support for future handshakes.
- Support for future CREATE2 cell types.
- Support for future EXTEND2 node specifiers
- Support for future relay crypto revisions
- Plan to deprecate older versions of the hs protocol.
- Plan for support of bigger keys for forward-secrecy at least.
DOCUMENTATION:
- replacement for rend-spec.txt
- more clarity in security analysis
"""
"""
HS improvements:
Anything I'm not commenting on below I generally agree with.
1 performance 1.1 reuse IPs (#8239) 1.2 torperf (#8510)
Did you get the right bug number? That ticket doesn't mention #8510.
1.3 scaling https://lists.torproject.org/pipermail/tor-dev/2013-October/005556.html 1.4 valet nodesIs this still useful given a cryptographic #8106 solution? The anti-enumeration part would seem to be taken care of. The anti-DoS part might be handy, or might deserve to get folded in somewhere else in the protocol.
1.5 lasse's "Improving Efficiency and Simplicity of Tor circuit establishment and hidden services" 1.5.1 big design change. maybe worth it. assumes valet nodes IIRCI'm not so sure this is a win; a lot of the cryptography seems obsoleted by ntor. I'm not enthusiastic about onion encryption, either.
We should definitely go over both of those last two with a fine-toothed comb though, and see what we *do* want to use from them. Did something you saw there attract you?
2 security 2.1 Crypto upgrade 2.1.1 Upgrade id keys [https://lists.torproject.org/pipermail/tor-dev/2013-October/005536.html] [https://lists.torproject.org/pipermail/tor-dev/2013-October/005534.html] 2.1.2 Upgrade IP service keys 2.1.3 Fix hybrid encryption (?) 2.2 Onion anti-harvesting (#8106) https://lists.torproject.org/pipermail/tor-dev/2013-October/005534.html 2.3 Guard node enumeration (#9001) 2.3.1 Virtual Circuits? Guard tiers?
Important but IMO orthogonal.
2.4 Unpredictable HSDirs (#8244) 2.5 Hide HS popularity 2.5.1 Oblivious transfer for HSDirs (is it needed if we have #8106? maybe yes.)I dunno; it's hard to do
2.5.2 Unlinkable introductions in IPs (is this even possible?) (do we even care? we have service keys)Service keys limit the linkability here, I agree.
3 Can we decrease the responsibility of guard nodes? It seems that security of HSes == their guard nodes, atm. 3.1 Implement stuff from https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-par... 3.2 Add optional padding/bitrate anti-fingerprinting transport for HSes. 3.2.1 Can be enabled by truly paranoid HSes. 3.2.2 But this is going to make HSes stand out even more! 3.2.3 These transports can all be broken anyway. Except a truly slow but theoretically secure padding/constant bitrate transport.
This all seems orthogonal.
3.3 What are other anonymous publishing protocols doing here? I2P seems to be weak here too, according to Grothoff's recent paper.4 misc 4.1 HSDirs system 4.1.1 Do we still need the hash ring even after #8106?
I think so. If we went back to a few directories, they'd be an obvious DoS target, *and* they could censor any HS for which they knew the public key.
What about mirroring HS descriptors to all directory servers (or a big subset of them), similar to how it's done for normal directory documents?
Drawbacks here include:
- Directory servers will have to store _many_ HS descriptors. Let's say that the size of an HS descriptor is 1kb and we have 100k Hidden Services, then there will be a 100MB overhead for each HS directory server.
- Since each DS will store all the HS descriptors, it will have a rough idea of the number of HSes in the network.
Positive changes are:
- We can simply forget all the hash ring code.
- We don't have to solve #8244.
- HSes become much harder to DoS on the HSDir-layer.
- HS directory requests for popular services spread through the whole network, not just through the 6 HSdirs.
More thinking needs to be done here. Especially to see if "mirror HS descriptors to all directory servers" scales (I would not be surprised if it doesn't).
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev