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

doc/TODO.021

@@ -187,6 +187,10 @@ N   . Draft proposal for GeoIP aggregation (see external constraints *)
       their choices even before they have the descriptors; and so
       authorities can put in more accurate numbers in the future.
 
+  - Spec compliance:
+    - Make sure that clients could do the new handshake without sending any
+      certs, if they wanted.
+
   - Tiny designs to write:
     - If a relay publishes a new descriptor with a significantly lower
       uptime or with a new IP address, then we should consider its current

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

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