[or-cvs] r9576: Merge proposal 106 into tor-spec.txt; reformat it slightly; (in tor/trunk: . doc/spec doc/spec/proposals)
nickm at seul.org
nickm at seul.org
Tue Feb 13 03:43:06 UTC 2007
Author: nickm
Date: 2007-02-12 22:43:03 -0500 (Mon, 12 Feb 2007)
New Revision: 9576
Modified:
tor/trunk/
tor/trunk/doc/spec/proposals/000-index.txt
tor/trunk/doc/spec/proposals/106-less-tls-constraint.txt
tor/trunk/doc/spec/tor-spec.txt
Log:
r11789 at catbus: nickm | 2007-02-12 22:42:58 -0500
Merge proposal 106 into tor-spec.txt; reformat it slightly; mark it closed.
Property changes on: tor/trunk
___________________________________________________________________
svk:merge ticket from /tor/trunk [r11789] on 8246c3cf-6607-4228-993b-4d95d33730f1
Modified: tor/trunk/doc/spec/proposals/000-index.txt
===================================================================
--- tor/trunk/doc/spec/proposals/000-index.txt 2007-02-13 02:01:38 UTC (rev 9575)
+++ tor/trunk/doc/spec/proposals/000-index.txt 2007-02-13 03:43:03 UTC (rev 9576)
@@ -24,5 +24,5 @@
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]
Modified: tor/trunk/doc/spec/proposals/106-less-tls-constraint.txt
===================================================================
--- tor/trunk/doc/spec/proposals/106-less-tls-constraint.txt 2007-02-13 02:01:38 UTC (rev 9575)
+++ tor/trunk/doc/spec/proposals/106-less-tls-constraint.txt 2007-02-13 03:43:03 UTC (rev 9576)
@@ -4,7 +4,7 @@
Last-Modified: $Date: 2007-01-30T07:50:01.643717Z $
Author: Nick Mathewson
Created:
-Status: Finished
+Status: Closed
Overview:
@@ -22,11 +22,11 @@
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 @@
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 @@
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
- an identity certificate. Internally to the code, we could assign the
- identity_digest field of these or_connections to a random number, or even
- not add them to the identity_digest->or_conn map.
-[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]
+ [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
+ identity_digest field of these or_connections to a random number, or even
+ not add them to the identity_digest->or_conn map.
+ [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]
-[2] Instead of using a restricted nickname character set that makes our
- commonName structure look unlike typical SSL certificates, we could treat
- the nickname as extending from the start of the commonName up to but not
- including the first non-nickname character.
+ [2] Instead of using a restricted nickname character set that makes our
+ commonName structure look unlike typical SSL certificates, we could treat
+ the nickname as extending from the start of the commonName up to but not
+ including the first non-nickname character.
- Alternatively, we could stop checking commonNames entirely. We don't
- actually _do_ anything based on the nickname in the certificate, so
- there's really no harm in letting every router have any commonName it
- wants.
-[this is the better choice -rd]
-[agreed. -nm]
+ Alternatively, we could stop checking commonNames entirely. We don't
+ actually _do_ anything based on the nickname in the certificate, so
+ there's really no harm in letting every router have any commonName it
+ wants.
+ [this is the better choice -rd]
+ [agreed. -nm]
REMAINING WAYS TO RECOGNIZE CLIENT->SERVER CONNECTIONS:
-Assuming that we removed the above requirements, we could then (in a later
-release) have clients not send certificates, and sometimes and started making
-our DNs a little less formulaic, client->server OR connections would still be
-recognizable by:
+ Assuming that we removed the above requirements, we could then (in a later
+ release) have clients not send certificates, and sometimes and started
+ making our DNs a little less formulaic, client->server OR connections would
+ 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 @@
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 @@
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
-DNs less recognizable:
+ If, in a later release, we have clients not send certificates, and we make
+ DNs less recognizable:
If clients don't send certs, servers don't need to verify them: win!
@@ -107,6 +107,6 @@
OTHER SPEC CHANGES:
-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
-wants.
+ 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
+ wants.
Modified: tor/trunk/doc/spec/tor-spec.txt
===================================================================
--- tor/trunk/doc/spec/tor-spec.txt 2007-02-13 02:01:38 UTC (rev 9575)
+++ tor/trunk/doc/spec/tor-spec.txt 2007-02-13 03:43:03 UTC (rev 9576)
@@ -149,7 +149,7 @@
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,9 +175,12 @@
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
- with malformed or missing certificates.
+ or missing certificates. ORs SHOULD NOT reject incoming connections from
+ 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
cells are CELL_LEN bytes long. Cells may be sent embedded in TLS
@@ -286,7 +289,7 @@
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.
More information about the tor-commits
mailing list