From 57847bfa4d42a889de07f22dd16fb1fdf5d2a1e3 Mon Sep 17 00:00:00 2001 From: Roger Dingledine Date: Sun, 21 Feb 2010 17:20:37 -0500 Subject: minor fixes in proposal 169 still need to finish reading it, but so far so good --- proposals/169-eliminating-renegotiation.txt | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) (limited to 'proposals/169-eliminating-renegotiation.txt') diff --git a/proposals/169-eliminating-renegotiation.txt b/proposals/169-eliminating-renegotiation.txt index 8a8ae6e..2c90f9c 100644 --- a/proposals/169-eliminating-renegotiation.txt +++ b/proposals/169-eliminating-renegotiation.txt @@ -31,7 +31,7 @@ Target: 0.2.2 In the current Tor TLS connection handshake protocol ("V2", or "renegotiating"), the parties begin with a single certificate sent from the server (responder) to the client (initiator), and - then renegotiated to a two-certs-from-each-authenticating party. + then renegotiate to a two-certs-from-each-authenticating party. We made this change to make Tor's handshake look like a browser speaking SSL to a webserver. (See proposal 130, and tor-spec.txt.) To tell whether to use the V1 or V2 handshake, @@ -77,12 +77,12 @@ Target: 0.2.2 certificate and let the handshake complete. - Do not accept any data until the client has renegotiated. - When the client is renegotiating, send a certificate - chain, and expect (possibly multiple certificates in - reply). + chain, and expect (possibly multiple) certificates in + reply. - Check the certificates when the renegotiation is done. Then exchange VERSIONS cells. - Late in 2009, researchers found a flaw in most application's use + Late in 2009, researchers found a flaw in most applications' use of TLS renegotiation: Although TLS renegotiation does not reauthenticate any information exchanged before the renegotiation takes place, many applications were treating it as though it did, @@ -118,10 +118,10 @@ Target: 0.2.2 with Tor cells instead of with TLS. Using _yet another_ variant response from the responder (server), - we allow the client to learn that doesn't need to rehandshake, - and it can use a cell-based authentication system. Once the + we allow the client to learn that it doesn't need to rehandshake + and can instead use a cell-based authentication system. Once the TLS handshake is done, the client and server exchange VERSIONS - cells to determine what link protocol version (including + cells to determine link protocol version (including handshake version). If they're using the handshake version specified here, the client and server arrive at link protocol version 3 (or higher), and use cells to exchange further @@ -134,7 +134,7 @@ Target: 0.2.2 handshake or later, so we can't encode more information there. We can, however, change the DN in the certificate passed by the - server to back the client. Currently, all V2 certificates are + server back to the client. Currently, all V2 certificates are generated with CN values ending with ".net". I propose that we have the ".net" commonName ending reserved to indicate the V2 protocol, and use commonName values ending with ".com" to @@ -220,7 +220,7 @@ Target: 0.2.2 cert for its identity. Tor instances MUST ignore any certificate with an unrecognized - CertType or CertPurpose. + CertType or CertPurpose, and MUST ignore extra bytes in the cert. The AUTHENTICATE cell proves to the server that the client with whom it completed the initial TLS handshake is the one possessing -- cgit v1.2.3-54-g00ecf