commit 0b0dae8c571183e39249b78d4d8fad989a090c1b
Author: Nick Mathewson <nickm(a)torproject.org>
Date: Wed Oct 5 10:10:09 2011 -0400
Revise 176 a little based on comments by steven on tor-dev
---
proposals/176-revising-handshake.txt | 41 ++++++++++++++++++---------------
1 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/proposals/176-revising-handshake.txt b/proposals/176-revising-handshake.txt
index 52a2d0a..0035fed 100644
--- a/proposals/176-revising-handshake.txt
+++ b/proposals/176-revising-handshake.txt
@@ -17,16 +17,16 @@ Supersedes: 169
and authenticate the original handshake, this proposal takes an
approach similar to Steven Murdoch's proposal 124 and my old
proposal 169, and uses Tor cells to finish authenticating the
- parties' identities once the initial TLS handshake is finished.
+ parties' identities once the initial TLS handshake is finished.spo
I discuss some alternative design choices and why I didn't make
them in section 7; please have a quick look there before
telling me that something is pointless or makes no sense.
- Terminological note: I use "client" below to mean the Tor
- instance (a client or a bridge or a relay) that initiates a TLS
- connection, and "server" to mean the Tor instance (a bridge or a
- relay) that accepts it.
+ Terminological note: I use "client" or "initiator" below to mean
+ the Tor instance (a client or a bridge or a relay) that initiates a
+ TLS connection, and "server" or "responder" to mean the Tor
+ instance (a bridge or a relay) that accepts it.
2. History and Motivation
@@ -359,16 +359,17 @@ Supersedes: 169
cell. If AuthType is 1 (meaning "RSA-SHA256-TLSSecret"), then the
Authentication contains the following:
- Type: The characters "AUTH0001" [8 octets]
+ TYPE: The characters "AUTH0001" [8 octets]
CID: A SHA256 hash of the client's RSA1024 identity key [32 octets]
SID: A SHA256 hash of the server's RSA1024 identity key [32 octets]
SLOG: A SHA256 hash of all bytes sent from the server to the client
as part of the negotiation up to and including the
AUTH_CHALLENGE cell; that is, the VERSIONS cell,
- the CERT cell, and the AUTH_CHALLENGE cell. [32 octets]
+ the CERT cell, the AUTH_CHALLENGE cell, and any padding cells.
+ [32 octets]
CLOG: A SHA256 hash of all bytes sent from the client to the
server as part of the negotiation so far; that is, the
- VERSIONS cell and the CERT cell. [32 octets]
+ VERSIONS cell and the CERT cell and any padding cells. [32 octets]
SCERT: A SHA256 hash of the server's TLS link
certificate. [32 octets]
TLSSECRETS: A SHA256 HMAC, using the TLS master secret as the
@@ -387,7 +388,8 @@ Supersedes: 169
[variable length]
To check the AUTHENTICATE cell, a server checks that all fields
- containing a hash contain the correct value, then verifies the
+ containing 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.
@@ -403,6 +405,9 @@ Supersedes: 169
would have supported version 3 or higher, but they somehow wound
up using a v2 or v1 handshake. (More on this in section 6.4.)
+ Either party may send a VPADDING cell at any time during the
+ handshake, except as the first cell. (See proposal 184.)
+
A server SHOULD NOT send any sequence of cells when starting a v3
negotiation other than "VERSIONS, CERT, AUTH_CHALLENGE,
NETINFO". A client SHOULD drop a CERT, AUTH_CHALLENGE, or
@@ -421,6 +426,7 @@ Supersedes: 169
We need to reserve command numbers for CERT, AUTH_CHALLENGE, and
AUTHENTICATE. I suggest that in link protocol 3 and higher, we
reserve a separate range of commands for variable-length cells.
+ See proposal 184 for more there.
5. Efficiency
@@ -474,15 +480,15 @@ Supersedes: 169
replayed or MITM'd AUTHENTICATE cell that was previously sent by
the client?
- If the client included a non-zero TLSSECRET component, and the
+ Because the client includes a TLSSECRET component, and the
server is able to verify it, then the answer is easy: the server
knows for certain that it is talking to the party with whom it
did the TLS handshake, since if somebody else generated a correct
TLSSECRET, they would have to know the master secret of the TLS
connection, which would require them to have broken TLS.
- If the client was not able to include a non-zero TLSSECRET
- component, or the server can't check it, the answer is a little
+ Even if the protocol didn't contain the TLSSECRET component,
+ the server could the client's authentication, but it's a little
trickier. The server knows that it is not getting a replayed
AUTHENTICATE cell, since the cell authenticates (among other
stuff) the server's AUTH_CHALLENGE cell, which it has never used
@@ -573,13 +579,10 @@ Supersedes: 169
used, it should prevent the use of the AUTHENTICATE cell for
anything other than the TLS connection the client had in mind.
- A signature of the TLSSECRET element on its own should be
- sufficient to prevent the attacks we care about, but because we
- don't necessarily have access to the TLS master secret when using
- a non-C TLS library, we can't depend on it. I added it anyway
- so that, if there is some problem with the rest of the protocol,
- clients and servers that _are_ written in C (that is, the official
- Tor implementation) can still be secure.
+ A signature of the TLSSECRET element on its own should also be
+ sufficient to prevent the attacks we care about. The redundancy
+ here should come in handy if I've made a mistake somewhere else in
+ my analysis.
If the client checks the server's certificates and matches them
to the TLS connection link key before proceding with the