Re: [tor-dev] Notes on HS revamping

[Nick Mathewson <nickm@xxxxxxxxxxxxxx>]

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.

>         4.1.2 Look into Valet nodes
>     4.2 petnames/human memorable onions?
>         4.2.1 maybe better as a third party (probably unofficial) plugin to tor/firefox
>     4.3 Read and compare with other HS-like designs. See:
>         4.3.1 I2P, GNUNet, rewebber, retroshare, "Anonymizing censorship resistant systems" by Serjantov, ...
>         4.3.2 Check uni-directional tunnels of I2P and their pros/cons.
>         4.3.3 http://freehaven.net/anonbib/

Don't forget freenet and tahoe-lafs.

>     4.4 Encrypted servives https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-encrypted-services.txt

Somewhat orthogonal.

> 5 What else should we do? How would we design HSes if we were not prejudiced by the current design?
>
> """
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev