[tor-commits] [torspec/master] fix typos and ambiguities from proposal 176 merge
arma at torproject.org
arma at torproject.org
Mon Oct 31 08:12:15 UTC 2011
commit 075e215564c76bbac983844d5c41d4d54a880595
Author: Roger Dingledine <arma at torproject.org>
Date: Mon Oct 31 04:12:00 2011 -0400
fix typos and ambiguities from proposal 176 merge
---
tor-spec.txt | 51 +++++++++++++++++++++++++++------------------------
1 files changed, 27 insertions(+), 24 deletions(-)
diff --git a/tor-spec.txt b/tor-spec.txt
index 7426659..52a9217 100644
--- a/tor-spec.txt
+++ b/tor-spec.txt
@@ -194,7 +194,8 @@ see tor-design.pdf.
[The above "should not" is because some of the ciphers that
clients list may be fake.]
- In "in-protocol" (a.k.a. "the v3 handshake"), the initiator sends no certificates, and the
+ In "in-protocol" (a.k.a. "the v3 handshake"), the initiator sends no
+ certificates, and the
responder sends a single connection certificate. The choice of
ciphersuites must be as in a "renegotiation" handshake. There are
additionally a set of constraints on the connection certificate,
@@ -212,7 +213,7 @@ see tor-design.pdf.
protocol version. Assuming that the version they negotiate is 3 (the
only one specified for use with this handshake right now), the
responder sends a CERTS cell, an AUTH_CHALLENGE cell, and a NETINFO
- cell to the initiator, which may send either CERTS,AUTHENTICATE,
+ cell to the initiator, which may send either CERTS, AUTHENTICATE,
NETINFO if it wants to authenticate, or just NETINFO if it does not.
For backward compatibility between later handshakes and "certificates
@@ -237,7 +238,7 @@ see tor-design.pdf.
All new relay implementations of the Tor protocol MUST support
backwards-compatible renegotiation; clients SHOULD do this too. If
- this is not possible, new client implementations MUST support all
+ this is not possible, new client implementations MUST support both
"renegotiation" and "in-protocol" and use the router's
published link protocols list (see dir-spec.txt on the "protocols" entry)
to decide which to use.
@@ -319,7 +320,7 @@ see tor-design.pdf.
Payload [Length bytes]
On a version 2 connection, variable-length cells are indicated by a
- command byte either equal to 7 ("VERSIONS"). On a version 3 or
+ command byte equal to 7 ("VERSIONS"). On a version 3 or
higher connection, variable-length cells are indicated by a command
byte equal to 7 ("VERSIONS"), or greater than or equal to 128.
@@ -382,9 +383,9 @@ see tor-design.pdf.
When the renegotiation handshake is used, both parties immediately
send a VERSIONS cell (4.1 below), and after negotiating a link
- protocol version (which will be 2), send a NETINFO cell (4.5 below) to
- confirm their addresses and timestamps. No other intervening cell
- types are allowed.
+ protocol version (which will be 2), each send a NETINFO cell (4.5
+ below) to confirm their addresses and timestamps. No other intervening
+ cell types are allowed.
When the in-protocol handshake is used, the initiator sends a
VERSIONS cell to indicate that it will not be renegotiating. The
@@ -392,11 +393,13 @@ see tor-design.pdf.
initiator the certificates it needs to learn the responder's
identity, an AUTH_CHALLENGE cell (4.3) that the initiator must include
as part of its answer if it chooses to authenticate, and a NETINFO
- cell (4.5). As soon as it gets the CERTS cell, the initiator knows
- whether the responder is correctly authenticated. At this point the
- initiator may send a NETINFO cell if it does not wish to
- authenticate, or a CERTS cell, an AUTHENTICATE cell (4.4), and a NETINFO
- cell if it does. When this handshake is in use, the first cell must
+ cell (4.5). The initiator can use the CERTS cell to confirm whether
+ the responder is correctly authenticated. If the initiator does not wish
+ to authenticate, it can send a NETINFO cell once it has received the
+ VERSIONS cell from the responder. If the initiator does wish to
+ authenticate, it waits until it gets the AUTH_CHALLENGE cell, and then
+ sends a CERTS cell, an AUTHENTICATE cell (4.4), and a NETINFO
+ cell. When this handshake is in use, the first cell must
still be VERSIONS, and no other cell type is allowed to intervene
besides those specified, except for PADDING and VPADDING cells.
@@ -414,8 +417,8 @@ see tor-design.pdf.
sent only one certificate at first and where the initiator did not
send any certificates in the first negotiation), both parties MUST
send a VERSIONS cell. In "renegotiation", they send a VERSIONS cell
- right after he renegotiation is finished, before any other cells are
- sent. In "in-protocol", the initiator send a VERSIONS cell
+ right after the renegotiation is finished, before any other cells are
+ sent. In "in-protocol", the initiator sends a VERSIONS cell
immediately after the initial TLS handshake, and the responder
replies immediately with a VERSIONS cell. Parties MUST NOT send any
other cells on a connection until they have received a VERSIONS cell.
@@ -435,7 +438,7 @@ see tor-design.pdf.
4.2. CERTS cells
- The CERT cell describes the keys that a Tor instance is claiming
+ The CERTS cell describes the keys that a Tor instance is claiming
to have. It is a variable-length cell. Its payload format is:
N: Number of certs in cell [1 octet]
@@ -444,7 +447,7 @@ see tor-design.pdf.
CLEN [2 octets]
Certificate [CLEN octets]
- Any extra octets at the end of a CERT cell MUST be ignored.
+ Any extra octets at the end of a CERTS cell MUST be ignored.
CertType values are:
1: Link key certificate certified by RSA1024 identity
@@ -470,7 +473,7 @@ see tor-design.pdf.
* The ID certificate is correctly self-signed.
Checking these conditions is sufficient to authenticate that the
initiator is talking to the Tor node with the expected identity,
- as certified in the ID certificate
+ as certified in the ID certificate.
To authenticate the initiator, the responder MUST check the
following:
@@ -486,8 +489,8 @@ see tor-design.pdf.
ID certificate.
* The ID certificate is correctly self-signed.
Checking these conditions is NOT sufficient to authenticate that the
- initiator has the ID it claims; to do so, the cells in 4.3 below must
- be exchanged.
+ initiator has the ID it claims; to do so, the cells in 4.3 and 4.4
+ below must be exchanged.
4.3. AUTH_CHALLENGE cells
@@ -510,8 +513,8 @@ see tor-design.pdf.
4.4. AUTHENTICATE cells
If an initiator wants to authenticate, it responds to the
- AUTH_CHALLENGE cell with a CERT cell and an AUTHENTICATE cell.
- The CERT cell is as a server would send, except that instead of
+ AUTH_CHALLENGE cell with a CERTS cell and an AUTHENTICATE cell.
+ The CERTS cell is as a server would send, except that instead of
sending a CertType 1 cert for an arbitrary link certificate, the
client sends a CertType 3 cert for an RSA AUTHENTICATE key.
(This difference is because we allow any link key type on a TLS
@@ -534,11 +537,11 @@ see tor-design.pdf.
SID: A SHA256 hash of the responder's RSA1024 identity key [32 octets]
SLOG: A SHA256 hash of all bytes sent from the responder to the
initiator as part of the negotiation up to and including the
- AUTH_CHALLENGE cell; that is, the VERSIONS cell, the CERT cell,
+ AUTH_CHALLENGE cell; that is, the VERSIONS cell, the CERTS cell,
the AUTH_CHALLENGE cell, and any padding cells. [32 octets]
CLOG: A SHA256 hash of all bytes sent from the initiator to the
responder as part of the negotiation so far; that is, the
- VERSIONS cell and the CERT cell and any padding cells. [32
+ VERSIONS cell and the CERTS cell and any padding cells. [32
octets]
SCERT: A SHA256 hash of the responder's TLS link certificate. [32
octets]
@@ -558,7 +561,7 @@ see tor-design.pdf.
[variable length]
To check the AUTHENTICATE cell, a responder checks that all fields
- containing from TYPE through TLSSECRETS contain their unique
+ from TYPE through TLSSECRETS contain their unique
correct values as described above, and then verifies the signature.
signature. The server MUST ignore any extra bytes in the signed
data after the SHA256 hash.
More information about the tor-commits
mailing list