Nick Mathewson <ni...@torproject.org> writes: > On Wed, Oct 16, 2013 at 9:18 PM, George Kadianakis <desnac...@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 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
