aboutsummaryrefslogtreecommitdiff
path: root/proposals/ideas/xxx-encrypted-services.txt
diff options
context:
space:
mode:
authorRoger Dingledine <arma@torproject.org>2011-02-14 05:59:43 -0500
committerRoger Dingledine <arma@torproject.org>2011-02-14 05:59:43 -0500
commit90d5958e0de826c5d054a80724d1ba460936d479 (patch)
tree461248c706b1e8b5bb1865c67b1294e92a597c3e /proposals/ideas/xxx-encrypted-services.txt
parent0ec18e2881477cf7ced6f274a5dae0086ac73b8b (diff)
downloadtorspec-90d5958e0de826c5d054a80724d1ba460936d479.tar.gz
torspec-90d5958e0de826c5d054a80724d1ba460936d479.zip
get a proposal i started last month into git
Diffstat (limited to 'proposals/ideas/xxx-encrypted-services.txt')
-rw-r--r--proposals/ideas/xxx-encrypted-services.txt74
1 files changed, 61 insertions, 13 deletions
diff --git a/proposals/ideas/xxx-encrypted-services.txt b/proposals/ideas/xxx-encrypted-services.txt
index 3414f3c..3c2ac67 100644
--- a/proposals/ideas/xxx-encrypted-services.txt
+++ b/proposals/ideas/xxx-encrypted-services.txt
@@ -1,18 +1,66 @@
+Filename: xxx-encrypted-services.txt
+Title: Encrypted services as a replacement to exit enclaving
+Author: Roger Dingledine
+Created: 2011-01-12
+Status: Draft
-the basic idea might be to generate a keypair, and sign little statements
-like "this key corresponds to this relay id", and publish them on karsten's
-hs dht.
+We should offer a way to run a Tor hidden service where the server-side
+rendezvous circuits are just one hop.
-so if you want to talk to it, you look it up, then go to that exit.
-and by 'go to' i mean 'build a tor circuit like normal except you're sure
-where to exit'
+1. Motivation
-connecting to it is slower than usual, but once you're connected, it's no
-slower than normal tor.
-and you get what wikileaks wants from its hidden service, which is really
-just the UI piece.
-indymedia also wants this.
+ There are three Tor use cases that this idea addresses:
-might be interesting to let an encrypted service list more than one relay,
-too.
+ 1) Indymedia wants to run an exit enclave that provides end-to-end
+ authentication and encryption. They tried running an exit relay that
+ just exits to themselves:
+ https://trac.torproject.org/projects/tor/ticket/800
+ but a) it handles lots of other traffic too since it's a relay, and
+ b) exit enclaves don't actually work consistently, because the first
+ connection from the user doesn't realize it should use the exit enclave.
+
+ 2) Wikileaks uses Tor hidden services not to hide their service,
+ but because the hidden service address provides a type of usability
+ we didn't think much about: unlike a more normal address, a Tor
+ hidden service address either works (meaning you get your end-to-end
+ authentication and encryption) or it fails hard. With a hidden service
+ address there's no way a user could accidentally submit their documents
+ to Wikileaks without using Tor, but with normal Tor it's possible.
+
+ 3) The Freenode IRC network wants to provide end-to-end encryption and
+ authentication to its users, a) to handle the fact that the IRC protocol
+ doesn't really provide much of that by default, and b) to funnel all
+ their Tor users into a single location so they can handle the anonymous
+ users better. They don't mind the fact that their service is hidden, but
+ they'd rather have better performance for their users given the choice.
+
+2. Design
+
+ It seems that the main changes required would be to a) make
+ circuit_launch_by_extend_info() know to use 1 hop rather than the
+ default, and know not to try to cannibalize a general 3-hop circ for
+ these circuits, and b) add a way in the torrc file to specify that this
+ service wants to be an encrypted service rather than a hidden service.
+
+ I had originally pondered some sort of even more efficient "signed
+ document saying this service is running at this Tor relay", which
+ would be more efficient because it would cut out the rendezvous step.
+ But by reusing the hidden service rendezvous infrastructure, we a)
+ blend in with hidden services (and hidden service descriptors) and
+ don't need to teach users (or their Tor clients) a new interface,
+ and b) can offer the encrypted service on a non-relay.
+
+ One design question to ponder: should we continue to use three-hop
+ circuits for our introduction points, and for publishing our encrypted
+ service descriptor? Probably.
+
+3. Security implications
+
+ There's a possible second-order effect here since both encrypted
+ services and hidden services will have foo.onion addresses and it's
+ not clear based on the address whether the service will be hidden --
+ if *some* .onion addresses are easy to track down, are we encouraging
+ adversaries to attack all rendezvous points just in case?
+
+...