[or-cvs] r17568: {tor} Clarify current client behavior WRT TLS certificates. Add a (in tor/trunk/doc: . spec spec/proposals)

[nickm@xxxxxxxx]

Author: nickm
Date: 2008-12-10 17:28:00 -0500 (Wed, 10 Dec 2008)
New Revision: 17568

Modified:
   tor/trunk/doc/TODO.021
   tor/trunk/doc/spec/proposals/098-todo.txt
   tor/trunk/doc/spec/tor-spec.txt
Log:
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.

Modified: tor/trunk/doc/TODO.021
===================================================================
--- tor/trunk/doc/TODO.021	2008-12-10 22:17:02 UTC (rev 17567)
+++ tor/trunk/doc/TODO.021	2008-12-10 22:28:00 UTC (rev 17568)
@@ -187,6 +187,10 @@
       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

Modified: tor/trunk/doc/spec/proposals/098-todo.txt
===================================================================
--- tor/trunk/doc/spec/proposals/098-todo.txt	2008-12-10 22:17:02 UTC (rev 17567)
+++ tor/trunk/doc/spec/proposals/098-todo.txt	2008-12-10 22:28:00 UTC (rev 17568)
@@ -65,6 +65,12 @@
     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

Modified: tor/trunk/doc/spec/tor-spec.txt
===================================================================
--- tor/trunk/doc/spec/tor-spec.txt	2008-12-10 22:17:02 UTC (rev 17567)
+++ tor/trunk/doc/spec/tor-spec.txt	2008-12-10 22:28:00 UTC (rev 17568)
@@ -251,6 +251,11 @@
    (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