Clarify current client behavior WRT TLS certificates. Add a TODO to make sure that this behavior is optional, and an entry in 098-todo.txt for investigating whether this behavior is smart.

svn:r17568

2 files changed, 11 insertions, 0 deletions

diff --git a/doc/spec/proposals/098-todo.txt b/doc/spec/proposals/098-todo.txt
index 2365a861fe..e891ea890c 100644
--- a/doc/spec/proposals/098-todo.txt
+++ b/doc/spec/proposals/098-todo.txt
@@ -65,6 +65,12 @@ Any time:
     distribution. Need to think harder about allowing values less than 3,
     and there's a tradeoff between having a wide variance and performance.
 
+  - Clients currently use certs during TLS.  Is this wise?  It does make it
+    easier for servers to tell which NATted client is which. We could use a
+    seprate set of certs for each guard, I suppose, but generating so many
+    certs could get expensive.  Omitting them entirely would make OP->OR
+    easier to tell from OR->OR.
+
 Things that should change...
 
 B.1. ... but which will require backward-incompatible change
diff --git a/doc/spec/tor-spec.txt b/doc/spec/tor-spec.txt
index 8c6508f6ee..8ab50242d9 100644
--- a/doc/spec/tor-spec.txt
+++ b/doc/spec/tor-spec.txt
@@ -251,6 +251,11 @@ see tor-design.pdf.
    (As an exception, directory servers may try to stay connected to all of
    the ORs -- though this will be phased out for the Tor 0.1.2.x release.)
 
+   To avoid being trivially distinguished from servers, client-only Tor
+   instances are encouraged but not required to use a two-certificate chain
+   as well.  Clients SHOULD NOT use keep using the same certificates when
+   their IP changes.  Clients MAY send no certificates at all.
+
 3. Cell Packet format
 
    The basic unit of communication for onion routers and onion