Changes required for safe txi2p use

diff --git a/docs/anonymity-roadmap.rst b/docs/anonymity-roadmap.rst
index 56aff644b5b1a5461cc949be5dab9028d7f120b1..2e2a78667f6deb940dd046cc47fb82e3ea89badc 100644 (file)
--- a/docs/anonymity-roadmap.rst
+++ b/docs/anonymity-roadmap.rst
@@ -22,6 +22,25 @@ Development phases
 2. Use I2p for network connectivity and protect identity of client
 
 * txi2p
+* Add "endpoint parameters" to Tahoe
+    * Servers provide the minimum client endpoint string required to connect to them:
+        * ``tcp:example.org:1337``
+        * ``ssl:example.org:443``
+        * ``i2p:longstring.b32.i2p``
+    * Clients may need to extend the strings with client-specific per-type parameters in order to successfully connect:
+        * ``tcp:example.org:1337:timeout=60``
+        * ``ssl:example.org:443:caCertsDir=/etc/ssl/certs``
+        * ``i2p:longstring.b32.i2p:tunnelNick=tahoe:inport=10000``
+    * These should be set in ``tahoe.cfg``:
+        * ``[node]clientEndpointParams = tcp:timeout=60,ssl:caCertsDir=/etc/ssl/certs,i2p:tunnelNick=tahoe:inport=10000``
+    * Tahoe parses, keeps an internal map, applies the relevant params to a client endpoint string before connecting
+* Client endpoint string whitelisting
+    * Server publishes an endpoint string for a client to connect to
+    * A malicious server could publish strings containing client-specific parameters that compromise the user
+        * Unsure what parameters could actually be used maliciously on their own, but definitely possible in concert with other attacks.
+    * The client should not accept strings that contain client-specific parameters
+        * How to tell the difference? Tahoe can't keep a list of everything that is safe.
+        * Maybe an endpoint API method that takes a client endpoint string and returns a safe one.
 
 
 3. endpoint-agnostic Foolscap server side