From 197310ac437a66fbbfced9ac4f92046c3a5ff248 Mon Sep 17 00:00:00 2001 From: David Stainton <dstainton415@gmail.com> Date: Fri, 5 Sep 2014 17:30:39 +0000 Subject: [PATCH] Removed I2P ticket info because it belongs in a trac ticket --- docs/anonymity-configuration.rst | 5 ++++- docs/anonymity-roadmap.rst | 28 +++++----------------------- 2 files changed, 9 insertions(+), 24 deletions(-) diff --git a/docs/anonymity-configuration.rst b/docs/anonymity-configuration.rst index e5a113b8..dddfe02f 100644 --- a/docs/anonymity-configuration.rst +++ b/docs/anonymity-configuration.rst @@ -233,7 +233,10 @@ I2p software deps here Configuration ============= -informative configuration info for i2p users +informative configuration info for i2p users goes here + +link to tahoe trac ticket regarding client endpoint string +parameter concatenation Performance and security issues of I2p (if applicable) diff --git a/docs/anonymity-roadmap.rst b/docs/anonymity-roadmap.rst index 2e2a7866..f99033d5 100644 --- a/docs/anonymity-roadmap.rst +++ b/docs/anonymity-roadmap.rst @@ -8,7 +8,7 @@ Anonymity Development Roadmap Development phases ================== -1. Use Tor for network connectivity and protect identity of client +1. Use Tor for network connectivity and to protect identity of client **note:** Client side is endpoint agnostic and server side has TCP endpoint support. @@ -19,29 +19,11 @@ Development phases * #517 -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. +2. Use I2p for network connectivity and to protect identity of client +**Dependencies** :: + * new Tahoe-LAFS trac ticket regarding client endpoint string parameter concatenation + * txi2p 3. endpoint-agnostic Foolscap server side -- 2.45.2