diff options
| -rw-r--r-- | doc/TODO | 9 | ||||
| -rw-r--r-- | doc/tor-spec.txt | 30 |
2 files changed, 29 insertions, 10 deletions
@@ -51,9 +51,13 @@ NICK pre1: pre2: - refer to things by key: - - extend cells need ip:port:identitykeyhash. + o extend cells need ip:port:identitykeyhash. + . Lookup routers and connections by key digest; accept hex + key digest in place of nicknames. + - Audit all uses of lookup-by-hostname and lookup-by-addr-port + to search by digest when appropriate. - also use this in intro points and rendezvous points, and - hidserv descs. + hidserv descs. [XXXX This isn't enough.] - figure out what to do about ip:port:differentkey ARMA - ORs connect on demand. attach circuits to new connections, keep create cells around somewhere, send destroy if fail. @@ -61,6 +65,7 @@ ARMA - ORs connect on demand. attach circuits to new connections, keep - running-routers list refers to nickname if verified, else hash-base64'ed. + pre3: - users can set their bandwidth, or we auto-detect it: - advertised bandwidth defaults to 10KB diff --git a/doc/tor-spec.txt b/doc/tor-spec.txt index d9940bc9c8..ec543cc72f 100644 --- a/doc/tor-spec.txt +++ b/doc/tor-spec.txt @@ -11,7 +11,7 @@ This is not a design document; most design criteria are not examined. For more information on why Tor acts as it does, see tor-design.pdf. TODO: (very soon) - - EXTEND cells should have hostnames or nicknames, so that OPs never + X EXTEND cells should have hostnames or nicknames, so that OPs never resolve OR hostnames. Else DNS servers can give different answers to different OPs, and compromise their anonymity. - Alternatively, directories should include IPs. @@ -68,13 +68,19 @@ TODO: (very soon) support any suite without ephemeral keys, symmetric keys of at least 128 bits, and digests of at least 160 bits. - An OR always sends a self-signed X.509 certificate whose commonName - is the server's nickname, and whose public key is in the server - directory. + An OR always sends two-certificate chain, consisting of a self-signed + certificate containing the OR's identity key, and of a second certificate + using a short-term connection key. The commonName of the second + certificate is the OR's nickname, and the commonName of the first + certificate is the OR's nickname, followed by a space and the string + "<identity>". - All parties receiving certificates must confirm that the public - key is as it appears in the server directory, and close the - connection if it is not. + All parties receiving certificates must confirm that the identity key is + as expected. (When initiating a connection, the expected identity key is + the one given in the directory; when creating a connection because of an + EXTEND cell, the expected identity key is the one given in the cell.) If + the key is not as expected, the party must close the connection if it is + not. Once a TLS connection is established, the two sides send cells (specified below) to one another. Cells are sent serially. All @@ -169,10 +175,18 @@ TODO: (very soon) The relay payload for an EXTEND relay cell consists of: Address [4 bytes] Port [2 bytes] + Public key hash [20 bytes] Onion skin [186 bytes] The port and address field denote the IPV4 address and port of the - next onion router in the circuit. + next onion router in the circuit; the public key hash is the SHA1 hash of + the ASN1 encoding of the next onion router's identity key. + + [XXXX Before 0.0.8, EXTEND cells did not include the public key hash. + Servers running 0.0.8 distinguish the old-style cells based on the length + of payloads. Clients running 0.0.8 check for servers version 0.0.7 or + later, and send them the old-style EXTEND cells. In a future release, + old-style EXTEND cells will not be supported.] The payload for a CREATED cell, or the relay payload for an EXTENDED cell, contains: |