r11789@catbus: nickm | 2007-02-12 22:42:58 -0500

 Merge proposal 106 into tor-spec.txt; reformat it slightly; mark it closed.


svn:r9576

doc/spec/proposals/000-index.txt

@@ -24,5 +24,5 @@ Proposals by number:
 103  Splitting identity key from regularly used signing key [OPEN]
 104  Long and Short Router Descriptors [OPEN]
 105  Version negotiation for the Tor protocol [OPEN]
-106  Checking fewer things during TLS handshakes [FINISHED]
+106  Checking fewer things during TLS handshakes [CLOSED]
 

doc/spec/proposals/106-less-tls-constraint.txt

@@ -4,7 +4,7 @@ Version: $Revision: 12105 $
 Last-Modified: $Date: 2007-01-30T07:50:01.643717Z $
 Author: Nick Mathewson
 Created:
-Status: Finished
+Status: Closed
 
 Overview:
 
@@ -22,11 +22,11 @@ Motivation:
 
 What we check now, and where we check it:
 
-tor_tls_check_lifetime:
+ tor_tls_check_lifetime:
     peer has certificate
     notBefore <= now <= notAfter
 
-tor_tls_verify:
+ tor_tls_verify:
     peer has at least one certificate
     There is at least one certificate in the chain
     At least one of the certificates in the chain is not the one used to
@@ -34,16 +34,16 @@ tor_tls_verify:
     The certificate _not_ used to negotiate the connection has signed the
         link cert
 
-tor_tls_get_peer_cert_nickname:
+ tor_tls_get_peer_cert_nickname:
     peer has a certificate.
     certificate has a subjectName.
     subjectName has a commonName.
     commonName consists only of characters in LEGAL_NICKNAME_CHARACTERS. [2]
 
-tor_tls_peer_has_cert:
+ tor_tls_peer_has_cert:
     peer has a certificate.
 
-connection_or_check_valid_handshake:
+ connection_or_check_valid_handshake:
     tor_tls_peer_has_cert [1]
     tor_tls_get_peer_cert_nickname [1]
     tor_tls_verify [1]
@@ -52,33 +52,33 @@ connection_or_check_valid_handshake:
     If we initiated the connection, then we got the identity digest we
         expected.
 
-USEFUL THINGS WE COULD DO:
+ USEFUL THINGS WE COULD DO:
 
-[1] We could just not force clients to have any certificate at all, let alone
+ [1] We could just not force clients to have any certificate at all, let alone
-    an identity certificate.  Internally to the code, we could assign the
+     an identity certificate.  Internally to the code, we could assign the
-    identity_digest field of these or_connections to a random number, or even
+     identity_digest field of these or_connections to a random number, or even
-    not add them to the identity_digest->or_conn map.
+     not add them to the identity_digest->or_conn map.
-[so if somebody connects with no certs, we let them. and mark them as
+ [so if somebody connects with no certs, we let them. and mark them as
-a client and don't treat them as a server. great. -rd]
+ a client and don't treat them as a server. great. -rd]
 
-[2] Instead of using a restricted nickname character set that makes our
+ [2] Instead of using a restricted nickname character set that makes our
-    commonName structure look unlike typical SSL certificates, we could treat
+     commonName structure look unlike typical SSL certificates, we could treat
-    the nickname as extending from the start of the commonName up to but not
+     the nickname as extending from the start of the commonName up to but not
-    including the first non-nickname character.
+     including the first non-nickname character.
 
-    Alternatively, we could stop checking commonNames entirely.  We don't
+     Alternatively, we could stop checking commonNames entirely.  We don't
-    actually _do_ anything based on the nickname in the certificate, so
+     actually _do_ anything based on the nickname in the certificate, so
-    there's really no harm in letting every router have any commonName it
+     there's really no harm in letting every router have any commonName it
-    wants.
+     wants.
-[this is the better choice -rd]
+ [this is the better choice -rd]
-[agreed. -nm]
+ [agreed. -nm]
 
 REMAINING WAYS TO RECOGNIZE CLIENT->SERVER CONNECTIONS:
 
-Assuming that we removed the above requirements, we could then (in a later
+ Assuming that we removed the above requirements, we could then (in a later
-release) have clients not send certificates, and sometimes and started making
+ release) have clients not send certificates, and sometimes and started
-our DNs a little less formulaic, client->server OR connections would still be
+ making our DNs a little less formulaic, client->server OR connections would
-recognizable by:
+ still be recognizable by:
     having a two-certificate chain sent by the server
     using a particular set of ciphersuites
     traffic patterns
@@ -86,7 +86,7 @@ recognizable by:
 
 OTHER IMPLICATIONS:
 
-If we stop verifying the above requirements:
+ If we stop verifying the above requirements:
 
     It will be slightly (but only slightly) more common to connect to a non-Tor
     server running TLS, and believe that you're talking to a Tor server (until
@@ -95,8 +95,8 @@ If we stop verifying the above requirements:
     It will be far easier for non-Tor SSL clients to accidentally connect to
     Tor servers and speak HTTPS or whatever to them.
 
-If, in a later release, we have clients not send certificates, and we make
+ If, in a later release, we have clients not send certificates, and we make
-DNs less recognizable:
+ DNs less recognizable:
 
     If clients don't send certs, servers don't need to verify them: win!
 
@@ -107,6 +107,6 @@ DNs less recognizable:
 
 OTHER SPEC CHANGES:
 
-When a client doesn't give us an identity, we should never extend any
+ When a client doesn't give us an identity, we should never extend any
-circuits to it (duh), and we should allow it to set circuit ID however it
+ circuits to it (duh), and we should allow it to set circuit ID however it
-wants.
+ wants.

doc/spec/tor-spec.txt

@@ -149,7 +149,7 @@ see tor-design.pdf.
    support any suite without ephemeral keys, symmetric keys of at
    least KEY_LEN bits, and digests of at least HASH_LEN bits.
 
-   Even though the connection protocol is identical, we think of the
+   Even though the connection protocol is identical, we will think of the
    initiator as either an onion router (OR) if it is willing to relay
    traffic for other Tor users, or an onion proxy (OP) if it only handles
    local requests. Onion proxies SHOULD NOT provide long-term-trackable
@@ -175,8 +175,11 @@ see tor-design.pdf.
    the key is not as expected, the party must close the connection.
 
    All parties SHOULD reject connections to or from ORs that have malformed
-   or missing certificates.  ORs MAY accept or reject connections from OPs
+   or missing certificates.  ORs SHOULD NOT reject incoming connections from
-   with malformed or missing certificates.
+   OPs with malformed or missing certificates.
+
+   [Before version 0.1.2.8-rc, ORs rejected incoming connections from ORs and
+   OPs alike if their certificates were missing or malformed.]
 
    Once a TLS connection is established, the two sides send cells
    (specified below) to one another.  Cells are sent serially.  All
@@ -286,7 +289,7 @@ see tor-design.pdf.
 
    The CircID for a CREATE cell is an arbitrarily chosen 2-byte integer,
    selected by the node (OP or OR) that sends the CREATE cell.  To prevent
-   CircID collisions, when one OR sends a CREATE cell to another, it chooses
+   CircID collisions, when one OR sends a CREATE cell to another OR, it chooses
    from only one half of the possible values based on the ORs' public
    identity keys: if the sending OR has a lower key, it chooses a CircID with
    an MSB of 0; otherwise, it chooses a CircID with an MSB of 1.