[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Notes on HS revamping
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@xxxxxxxxxx> wrote:
> Nick Mathewson <nickm@xxxxxxxxxxxxxx> writes:
>
>> On Wed, Oct 16, 2013 at 9:18 PM, George Kadianakis <desnacked@xxxxxxxxxx> 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 nodes
>>
>> Is 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 IIRC
>>
>> I'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-parameters
>>> 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@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev