commit 0b0dae8c571183e39249b78d4d8fad989a090c1b Author: Nick Mathewson <nickm@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