From 3d612ed7e7a8dad1aacbf209e4a584132c53fcd1 Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Tue, 13 Feb 2007 03:43:03 +0000 Subject: r11789@catbus: nickm | 2007-02-12 22:42:58 -0500 Merge proposal 106 into tor-spec.txt; reformat it slightly; mark it closed. svn:r9576 --- proposals/106-less-tls-constraint.txt | 66 +++++++++++++++++------------------ 1 file changed, 33 insertions(+), 33 deletions(-) (limited to 'proposals/106-less-tls-constraint.txt') diff --git a/proposals/106-less-tls-constraint.txt b/proposals/106-less-tls-constraint.txt index f44532e..6f53497 100644 --- a/proposals/106-less-tls-constraint.txt +++ b/proposals/106-less-tls-constraint.txt @@ -4,7 +4,7 @@ Version: $Revision: 12105 $ Last-Modified: $Date: 2007-01-30T07:50:01.643717Z $ Author: Nick Mathewson Created: -Status: Finished +Status: Closed Overview: @@ -22,11 +22,11 @@ Motivation: What we check now, and where we check it: -tor_tls_check_lifetime: + tor_tls_check_lifetime: peer has certificate notBefore <= now <= notAfter -tor_tls_verify: + tor_tls_verify: peer has at least one certificate There is at least one certificate in the chain At least one of the certificates in the chain is not the one used to @@ -34,16 +34,16 @@ tor_tls_verify: The certificate _not_ used to negotiate the connection has signed the link cert -tor_tls_get_peer_cert_nickname: + tor_tls_get_peer_cert_nickname: peer has a certificate. certificate has a subjectName. subjectName has a commonName. commonName consists only of characters in LEGAL_NICKNAME_CHARACTERS. [2] -tor_tls_peer_has_cert: + tor_tls_peer_has_cert: peer has a certificate. -connection_or_check_valid_handshake: + connection_or_check_valid_handshake: tor_tls_peer_has_cert [1] tor_tls_get_peer_cert_nickname [1] tor_tls_verify [1] @@ -52,33 +52,33 @@ connection_or_check_valid_handshake: If we initiated the connection, then we got the identity digest we expected. -USEFUL THINGS WE COULD DO: + USEFUL THINGS WE COULD DO: -[1] We could just not force clients to have any certificate at all, let alone - an identity certificate. Internally to the code, we could assign the - identity_digest field of these or_connections to a random number, or even - not add them to the identity_digest->or_conn map. -[so if somebody connects with no certs, we let them. and mark them as -a client and don't treat them as a server. great. -rd] + [1] We could just not force clients to have any certificate at all, let alone + an identity certificate. Internally to the code, we could assign the + identity_digest field of these or_connections to a random number, or even + not add them to the identity_digest->or_conn map. + [so if somebody connects with no certs, we let them. and mark them as + a client and don't treat them as a server. great. -rd] -[2] Instead of using a restricted nickname character set that makes our - commonName structure look unlike typical SSL certificates, we could treat - the nickname as extending from the start of the commonName up to but not - including the first non-nickname character. + [2] Instead of using a restricted nickname character set that makes our + commonName structure look unlike typical SSL certificates, we could treat + the nickname as extending from the start of the commonName up to but not + including the first non-nickname character. - Alternatively, we could stop checking commonNames entirely. We don't - actually _do_ anything based on the nickname in the certificate, so - there's really no harm in letting every router have any commonName it - wants. -[this is the better choice -rd] -[agreed. -nm] + Alternatively, we could stop checking commonNames entirely. We don't + actually _do_ anything based on the nickname in the certificate, so + there's really no harm in letting every router have any commonName it + wants. + [this is the better choice -rd] + [agreed. -nm] REMAINING WAYS TO RECOGNIZE CLIENT->SERVER CONNECTIONS: -Assuming that we removed the above requirements, we could then (in a later -release) have clients not send certificates, and sometimes and started making -our DNs a little less formulaic, client->server OR connections would still be -recognizable by: + Assuming that we removed the above requirements, we could then (in a later + release) have clients not send certificates, and sometimes and started + making our DNs a little less formulaic, client->server OR connections would + still be recognizable by: having a two-certificate chain sent by the server using a particular set of ciphersuites traffic patterns @@ -86,7 +86,7 @@ recognizable by: OTHER IMPLICATIONS: -If we stop verifying the above requirements: + If we stop verifying the above requirements: It will be slightly (but only slightly) more common to connect to a non-Tor server running TLS, and believe that you're talking to a Tor server (until @@ -95,8 +95,8 @@ If we stop verifying the above requirements: It will be far easier for non-Tor SSL clients to accidentally connect to Tor servers and speak HTTPS or whatever to them. -If, in a later release, we have clients not send certificates, and we make -DNs less recognizable: + If, in a later release, we have clients not send certificates, and we make + DNs less recognizable: If clients don't send certs, servers don't need to verify them: win! @@ -107,6 +107,6 @@ DNs less recognizable: OTHER SPEC CHANGES: -When a client doesn't give us an identity, we should never extend any -circuits to it (duh), and we should allow it to set circuit ID however it -wants. + When a client doesn't give us an identity, we should never extend any + circuits to it (duh), and we should allow it to set circuit ID however it + wants. -- cgit v1.2.3-54-g00ecf