Re: [tor-dev] Notes on HS revamping

[George Kadianakis <desnacked@xxxxxxxxxx>]

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