diff --git a/doc/spec/proposals/000-index.txt b/doc/spec/proposals/000-index.txt index 398b9410d9..d4de5b44b2 100644 --- a/doc/spec/proposals/000-index.txt +++ b/doc/spec/proposals/000-index.txt @@ -64,6 +64,7 @@ Proposals by number: 139 Download consensus documents only when it will be trusted [CLOSED] 140 Provide diffs between consensuses [OPEN] 141 Download server descriptors on demand [DRAFT] +142 Combine Introduction and Rendezvous Points [OPEN] Proposals by status: @@ -81,6 +82,7 @@ Proposals by status: 121 Hidden Service Authentication 137 Keep controllers informed as Tor bootstraps 140 Provide diffs between consensuses + 142 Combine Introduction and Rendezvous Points NEEDS-REVISION: 110 Avoiding infinite length circuits 117 IPv6 exits diff --git a/doc/spec/proposals/142-combine-intro-and-rend-points.txt b/doc/spec/proposals/142-combine-intro-and-rend-points.txt new file mode 100644 index 0000000000..3e835ec1cc --- /dev/null +++ b/doc/spec/proposals/142-combine-intro-and-rend-points.txt @@ -0,0 +1,280 @@ +Filename: 142-combine-intro-and-rend-points.txt +Title: Combine Introduction and Rendezvous Points +Version: $Revision$ +Last-Modified: $Date$ +Author: Karsten Loesing, Christian Wilms +Created: 27-Jun-2008 +Status: Open + +Change history: + + 27-Jun-2008 Initial proposal for or-dev + +Overview: + + Establishing a connection to a hidden service currently involves two Tor + relays, introduction and rendezvous point, and 10 more relays distributed + over four circuits to connect to them. The introduction point is + established in the mid-term by a hidden service to transfer introduction + requests from client to the hidden service. The rendezvous point is set + up by the client for a single hidden service request and actually + transfers end-to-end encrypted application data between client and hidden + service. + + There are some reasons for separating the two roles of introduction and + rendezvous point: (1) Plausible deniability: A relay shall not be made + responsible that it relays data for a certain hidden service; in the + original design as described in [1] an introduction point relays no + application data, and a rendezvous points neither knows the hidden + service nor can it decrypt the data. (2) Scalability: The hidden service + shall not have to maintain a number of open circuits proportional to the + expected number of client requests. (3) Attack resistance: The effect of + an attack on the only visible parts of a hidden service, its introduction + points, shall be as small as possible. + + However, elimination of a separate rendezvous connection as proposed by + Øverlier and Syverson [2] is the most promising approach to improve the + delay in connection establishment. From all substeps of connection + establishment extending a circuit by only a single hop is responsible for + a major part of delay. Reducing on-demand circuit extensions from two to + one results in a decrease of mean connection establishment times from 39 + to 29 seconds [3]. Particularly, eliminating the delay on hidden-service + side allows the client to better observe progress of connection + establishment, thus allowing it to use smaller timeouts. Proposal 114 + introduced new introduction keys for introduction points and provides for + user authorization data in hidden service descriptors; it will be shown + in this proposal that introduction keys in combination with new + introduction cookies provide for the first security property of plausible + deniability. Further, eliminating the need for a separate introduction + connection benefits the overall network load by decreasing the number of + circuit extensions. After all, having only one connection between client + and hidden service reduces the overall protocol complexity. + +Design: + + 1. Hidden Service Configuration + + Hidden services should be able to choose whether they would like to use + this protocol. This might be opt-in for 0.2.1.x and opt-out for later + major releases. + + 2. Contact Point Establishment + + When preparing a hidden service, a Tor client selects a set of relays to + act as contact points instead of introduction points. The contact point + combines both roles of introduction and rendezvous point as proposed in + [2]. The only requirement for a relay to be picked as contact point is + its capability of performing this role. This can be determined from the + Tor version number that needs to be equal or higher than the first + version that implements this proposal. + + The easiest way to implement establishment of contact points is to + introduce v2 ESTABLISH_INTRO cells and use the currently unused auth type + number 1 for contact points. + + V Format byte: set to 255 [1 octet] + V Version byte: set to 2 [1 octet] + KLEN Key length [2 octets] + PK Bob's public key [KLEN octets] + HS Hash of session info [20 octets] + AUTHT The auth type that is supported [1 octet] + AUTHL Length of auth data [2 octets] + AUTHD Auth data [variable] + SIG Signature of above information [variable] + + The hidden service does not create a fixed number of contact points, like + 3 in the current protocol. It uses a minimum of 3 contact points, but + increases this number depending on the history of client requests within + the last hour. The hidden service also increases this number depending on + the frequency of failing contact points in order to defend against + attacks on its contact points. When client authorization as described in + proposal 121 is used, a hidden service can also use the number of + authorized clients as first estimate for the required number of contact + points. + + 3. Hidden Service Descriptor Creation + + A hidden service needs to issue a fresh introduction cookie for each + established introduction point. By requiring clients to use this cookie + in a later connection establishment, an introduction point cannot access + the hidden service that it works for. Together with the fresh + introduction key that was introduced in proposal 114, this results in + plausible deniability for the contact point. + + The v2 hidden service descriptor format contains an + "intro-authentication" field that may contain introduction-point specific + keys. The hidden service creates a random string, comparable to the + rendezvous cookie, and includes it in the descriptor as introduction + cookie. Existing clients that do not understand this new protocol simply + ignore that cookie. Further, the hidden service lists in the + "protocol-versions" field that it supports this protocol. + + 4. Connection Establishment + + When establishing a connection to a hidden service a client learns about + the capability of using the new protocol from the hidden service + descriptor. It may choose whether to use this new protocol or not, + whereas older clients cannot understand the new capability and can only + use the current protocol. Client using version 0.2.1.x should be able to + opt-in for using the new protocol, which should change to opt-out for + later major releases. + + When using the new capability the client creates a v2 INTRODUCE1 cell + that extends an unversioned INTRODUCE1 cell by adding the content of an + ESTABLISH_RENDEZVOUS cell. Further, the client sends this cell using the + new cell type 41 RELAY_INTRODUCE1_VERSIONED to the introduction point, + because unversioned and versioned INTRODUCE1 cells are indistinguishable: + + Cleartext + V Version byte: set to 2 [1 octet] + PK_ID Identifier for Bob's PK [20 octets] + AUTHT The auth type that is supported [1 octet] + AUTHL Length of auth data [2 octets] + AUTHD Auth data [variable] + Encrypted to Bob's PK: + VER Version byte: set to 3. [1 octet] + AUTHT The auth type that is supported [1 octet] + AUTHL Length of auth data [2 octets] + AUTHD Auth data [variable] + IP Rendezvous point's address [4 octets] + PORT Rendezvous point's OR port [2 octets] + ID Rendezvous point identity ID [20 octets] + KLEN Length of onion key [2 octets] + KEY Rendezvous point onion key [KLEN octets] + RC Rendezvous cookie [20 octets] + g^x Diffie-Hellman data, part 1 [128 octets] + + The cleartext part contains the rendezvous cookie as auth data for the + currently unused auth type 1. The contact point remembers the rendezvous + cookie just as a rendezvous point would do. + + The encrypted part contains the introduction cookie as auth data for the + likewise unused auth type 1. The rendezvous cookie is contained as + before, but the remaining rendezvous point information is left empty, as + there is no separate rendezvous point. + + 5. Rendezvous Establishment + + The contact point recognizes a v2 INTRODUCE1 cell with auth type 1 as a + request to be used in the new protocol. It remembers the contained + rendezvous cookie, replies to the client with an INTRODUCE_ACK cell + (omitting the RENDEZVOUS_ESTABLISHED cell), and forwards the encrypted + part of the INTRODUCE1 cell as INTRODUCE2 cell to the hidden service. + + 6. Introduction at Hidden Service + + The hidden services recognizes an INTRODUCE2 cell containing an + introduction cookie as authorization data. In this case, it does not + extend a circuit to a rendezvous point, but sends a RENDEZVOUS1 cell + directly back to its contact point as usual. + + 7. Rendezvous at Contact Point + + The contact point processes a RENDEZVOUS1 cell just as a rendezvous point + does. The only difference is that the hidden-service-side circuit is not + exclusive for the client connection, but shared among multiple client + connections. + +Security Implications: + + (1) Plausible deniability + + One of the original reasons for the separation of introduction and + rendezvous points is that a relay shall not be made responsible that it + relays data for a certain hidden service. In the current design an + introduction point relays no application data and a rendezvous points + neither knows the hidden service nor can it decrypt the data. + + This property is also fulfilled in this new design. A contact point only + learns a fresh introduction key instead of the hidden service key, so + that it cannot recognize a hidden service. Further, the introduction + cookie, which is unknown to the contact point, prevents it from accessing + the hidden service itself. The only way for a contact point to access a + hidden service is to look up whether it is contained in the descriptors + of known hidden services. A contact point can plausibly deny knowledge of + any hidden services, so that it cannot know for which hidden service it + is working. In addition to that, it cannot learn the data that it + transfers, because all communication between client and hidden service + are end-to-end encrypted. + + (2) Scalability + + Another goal of the existing hidden service protocol is that a hidden + service does not have to maintain a number of open circuits proportional + to the expected number of client requests. The rationale behind this is + better scalability. + + The new protocol eliminates the need for a hidden service to extend + circuits on demand, which has a positive effect circuits establishment + times and overall network load. The solution presented here to establish + a number of contact points proportional to the history of connection + requests reduces the number of circuits to a minimum number that fits the + hidden service's needs. + + (3) Attack resistance + + The third goal of separating introduction and rendezvous points is to + limit the effect of an attack on the only visible parts of a hidden + service which are the contact points in this protocol. + + In theory, the new protocol is more vulnerable to this attack. An + attacker who can take down a contact point does not only eliminate an + access point to the hidden service, but also breaks current client + connections to the hidden service using that contact point. + + Øverlier and Syverson proposed the concept of valet nodes as additional + safeguard for introduction/contact points [4]. Unfortunately, this + increases hidden service protocol complexity conceptually and from an + implementation point of view. Therefore, it is not included in this + proposal. + + However, in practice attacking a contact point (or introduction point) is + not as rewarding as it might appear. The cost for a hidden service to set + up a new contact point and publish a new hidden service descriptor is + minimal compared to the efforts necessary for an attacker to take a Tor + relay down. As a countermeasure to further frustrate this attack, the + hidden service raises the number of contact points as a function of + previous contact point failures. + + Further, the probability of breaking client connections due to attacking + a contact point is minimal. It can be assumed that the probability of one + of the other five involved relays in a hidden service connection failing + or being shut down is higher than that of a successful attack on a + contact point. + + (4) Resistance against Locating Attacks + + Clients are no longer able to force a hidden service to create or extend + circuits. This further reduces an attacker's capabilities of locating a + hidden server as described by Øverlier and Syverson [5]. + +Compatibility: + + The presented protocol does not raise compatibility issues with current + Tor versions. New relay versions support both, the existing and the + proposed protocol as introduction/rendezvous/contact points. A contact + point acts as introduction point simultaneously. Hidden services and + clients can opt-in to use the new protocol which might change to opt-out + some time in the future. + +References: + + [1] Roger Dingledine, Nick Mathewson, and Paul Syverson, Tor: The + Second-Generation Onion Router. In the Proceedings of the 13th USENIX + Security Symposium, August 2004. + + [2] Lasse Øverlier and Paul Syverson, Improving Efficiency and Simplicity + of Tor Circuit Establishment and Hidden Services. In the Proceedings of + the Seventh Workshop on Privacy Enhancing Technologies (PET 2007), + Ottawa, Canada, June 2007. + + [3] Christian Wilms, Improving the Tor Hidden Service Protocol Aiming at + Better Performance, diploma thesis, June 2008, University of Bamberg. + + [4] Lasse Øverlier and Paul Syverson, Valet Services: Improving Hidden + Servers with a Personal Touch. In the Proceedings of the Sixth Workshop + on Privacy Enhancing Technologies (PET 2006), Cambridge, UK, June 2006. + + [5] Lasse Øverlier and Paul Syverson, Locating Hidden Servers. In the + Proceedings of the 2006 IEEE Symposium on Security and Privacy, May 2006. +