commit a91864ceaa6c4a83d4cd86fa146868e89599ea92 Author: Roger Dingledine arma@torproject.org Date: Sun Jul 12 18:10:55 2015 -0400
add proposal 246 from special and asn --- proposals/000-index.txt | 4 +- proposals/246-merge-hsdir-and-intro.txt | 296 +++++++++++++++++++++++++++++++ 2 files changed, 299 insertions(+), 1 deletion(-)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt index f8e959d..e22707f 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -166,6 +166,7 @@ Proposals by number: 243 Give out HSDir flag only to relays with Stable flag [OPEN] 244 Use RFC5705 Key Exporting in our AUTHENTICATE calls [DRAFT] 245 Deprecating and removing the TAP circuit extension protocol [DRAFT] +246 Merging Hidden Service Directories and Introduction Points [OPEN]
Proposals by status: @@ -224,9 +225,10 @@ Proposals by status: 233 Making Tor2Web mode faster 234 Adding remittance field to directory specification 236 The move to a single guard node - 237 All relays are directory servers [for 0.2.6.x] + 237 All relays are directory servers [for 0.2.7.x] 242 Better performance and usability for the MyFamily option 243 Give out HSDir flag only to relays with Stable flag + 246 Merging Hidden Service Directories and Introduction Points ACCEPTED: 140 Provide diffs between consensuses 172 GETINFO controller option for circuit information diff --git a/proposals/246-merge-hsdir-and-intro.txt b/proposals/246-merge-hsdir-and-intro.txt new file mode 100644 index 0000000..874714f --- /dev/null +++ b/proposals/246-merge-hsdir-and-intro.txt @@ -0,0 +1,296 @@ +Filename: 246-merge-hsdir-and-intro.txt +Title: Merging Hidden Service Directories and Introduction Points +Author: John Brooks, George Kadianakis +Created: 2015-07-12 +Status: Open + +1. Overview and Motivation + + This document describes a modification to proposal 224 ("Next-Generation + Hidden Services in Tor"), which simplifies and improves the architecture by + combining hidden service directories and introduction points at the same + relays. + + A reader will want to be familiar with the existing hidden service design, + and with the changes in proposal 224. If accepted, this proposal should be + combined with proposal 224 to make a superseding specification. + +1.1. Overview + + In the existing hidden service design and proposal 224, there are three + distinct steps building a connection: fetching the descriptor from a + directory, contacting an introduction point listed in the descriptor, and + rendezvous as specified during the introduction. The hidden service + directories are selected algorithmically, and introduction points are + selected at random by the service. + + We propose to combine the responsibilities of the introduction point and + hidden service directory. The list of introduction points responsible for a + service will be selected using the algorithm specified for HSDirs [proposal + 224, section 2.2.3]. The service builds a long-term introduction circuit to + each of these, identified by its blinded public key. Clients can calculate + the same set of relays, build an introduction circuit, retrieve the + ephemeral keys, and proceed with sending an introduction to the service in + the same ways as before. + +1.2. Benefits over proposal 224 + + With this change, client connections are made more efficient by needing only + two circuits (for introduction and rendezvous), instead of the three needed + previously, and need to contact fewer relays. Clients also no longer cache + descriptors, which substantially simplifies code and removes a common source + of bugs and reliability issues. + + Hidden services are able to stay online by simply maintaining their + introduction circuits; there is no longer a need to periodically update + descriptors. This reduces network load and traffic fingerprinting + opportunities for a hidden service. + + The number and churn of relays a hidden service depends on is also reduced. + In particular, prior hidden service designs may frequently choose new + introduction points, and each of these has an opportunity to observe the + popularity or connection behavior of clients. + +1.3. Other effects on proposal 224 + + An adversarial introduction point is not significantly more capable than a + hidden service directory under proposal 224. The differences are: + + 1. The introduction point maintains a long-lived circuit with the service + 2. The introduction point can break that circuit and cause the service to + rebuild it + + See section 4 ("Discussion") for other impacts and open discussion + questions. + +2. Specification + +2.1. Picking introduction points for a service + + Instead of picking HSDirs, hidden services pick their introduction points + using the same algorithm as defined in proposal 224 section 2.2 [HASHRING]. + + To be used as an introduction point, a relay must have the Stable flag in + the consensus and an uptime of at least twice the shared random period + defined in proposal 224 section 2.3. + + This also specifies the lifetime of introduction points, since they will be + rotated with the change of time period and shared randomness. + +2.2. Hidden service sets up introduction points + + After a hidden service has picked its intro points, it needs to establish + long-term introduction circuits to them and also send them an encrypted + descriptor that should be forwarded to potential clients. The descriptor + contains a service key that should be used by clients to encrypt the + INTRODUCE1 cell that will be sent to the hidden service. The encrypted parts + of the descriptor are encrypted with the symmetric keys specified in prop224 + section [ENCRYPTED-DATA]. + +2.2.1. Hidden service uploads a descriptor + + Services post a descriptor by opening a directory stream with BEGIN_DIR, and + sending a HTTP POST request as described in proposal 224, section 2.2.4. + + The relay must verify the signatures of the descriptor, and check whether it + is responsible for that blinded public key in the hash ring. Relays should + connect the descriptor to the circuit used to upload it, which will be + repurposed as the service introduction circuit. The descriptor does not need + to be cached by the introduction point after that introduction circuit has + closed. + + It is unexpected and invalid to send more than one descriptor on the same + introduction circuit. + +2.2.2. Descriptor format + + The format for the hidden service descriptor is as described in proposal 224 + sections 2.4 and 2.5, with the following modifications: + + * The "revision-counter" field is removed + * The introduction-point section is removed + * The "auth-key" field is removed + * The "enc-key legacy" field is removed + * The "enc-key ntor" field must be specified exactly once per descriptor + + Unlike previous versions, the descriptor does not encode the entire list of + introduction points. The descriptor only contains a key for the particular + introduction point it was sent to. + +2.2.3. ESTABLISH_INTRO cell + + When a hidden service is establishing a new introduction point, it sends the + ESTABLISH_INTRO cell, which is formatted as described by proposal 224 + section 3.1.1, except for the following: + + The AUTH_KEY_TYPE value 02 is changed to: + + [02] -- Signing key certificate cross-certified with the blinded key, in + the same format as in the hidden service descriptor. + + In this case, SIG is a signature of the cell with the signing key specified + in AUTH_KEY. The relay must verify this signature, as well as the + certification with the blinded key. The relay should also verify that it has + received a valid descriptor with this blinded key. + + [XXX: Other options include putting only the blinded key, or only the + signing key in this cell. In either of these cases, we must look up the + descriptor to fully validate the contents, but we require the descriptor + to be present anyway. -special] + + [XXX: What happens with the MAINT_INTRO process defined in proposal 224 + section 3.1.3? -special] + +2.3. Client connection to a service + + A client that wants to connect to a hidden service should first calculate + the responsible introduction points for the onion address as described in + section 2.1 above. + + The client chooses one introduction point at random, builds a circuit, and + fetches the descriptor. Once it has received, verified, and decrypted the + descriptor, the client can use the same circuit to send the INTRODUCE1 cell. + +2.3.1. Client requests a descriptor + + Clients can request a descriptor by opening a directory stream with + BEGIN_DIR, and sending a HTTP GET request as described in proposal 224, + section 2.2.4. + + The client must verify the signatures of the descriptor, and decrypt the + encrypted portion to access the "enc-key". This key is used to encrypt the + contents of the INTRODUCE1 cell to the service. + + Because the descriptor is specific to each introduction point, client-side + descriptor caching changes significantly. There is little point in caching + these descriptors, because they are inexpensive to request and will always + be available when a service-side introduction circuit is available. A client + that does caching must be prepared to handle INTRODUCE1 failures due to + rotated keys. + +2.3.2. Client sends INTRODUCE1 + + After requesting the descriptor, the client can use the same circuit to send + an INTRODUCE1 cell, which is forwarded to the service and begins the + rendezvous process. + + The INTRODUCE1 cell is the same as proposal 224 section 3.2.1, except that + the AUTH_KEYID is the blinded public key, instead of the now-removed + introduction point authentication key. + + The relay must permit this circuit to change purpose from the directory + request to a client or server introduction. + +3. Other changes to proposal 224 + +3.1. Removing proposal 224 legacy relay support + + Proposal 224 defines a process for using legacy relays as introduction + points; see section 3.1.2 [LEGACY_EST_INTRO], and 3.2.3 [LEGACY-INTRODUCE1]. + With the changes to the introduction point in this proposals, it's no longer + possible to maintain support for legacy introduction points. + + These sections of proposal 224 are removed, along with other references to + legacy introduction points and RSA introduction point keys. We will need to + handle the migration process to ensure that sufficient relays are available + as introduction points. See the discussion in section 4.1 for more details. + +3.2. Removing the "introduction point authentication key" + + The "introduction point authentication key" defined in proposal 224 is + removed. The "descriptor signing key" is used to sign descriptors and the + ESTABLISH_INTRO2 cell. Descriptors are unique for each introduction point, + and there is no point in generating a new key used only to sign the + ESTABLISH_INTRO2 cell. + +4. Discussion + +4.1. No backwards compatibility with legacy relays + + By changing the introduction procedure in such a way, we are unable to + maintain backwards compatibility. That is, hidden services will be unable to + use old relays as their introduction points, and similarly clients will be + unable to introduce through old relays. + + To maintain an adequate anonymity set of intro points, clients and hidden + services should perform this introduction method only after most relays have + upgraded. For this reason we introduce the consensus parameter + HSMergedIntroduction which controls whether hidden services should perform + this merged introduction or fall back to the old one. + + [XXX: Do we? This sounds like we have to implement both in the client, which + I thought we wanted to avoid. An alternative is to make sure that the intro + point side is done early enough, and that clients know not to rely on the + security of 224 services until enough relays are upgraded and the + implementation is done. -special] + +4.2. Restriction on the number of intro points and impact on load balancing + + One drawback of this proposal is that the number of introduction points of a + hidden service is now a constant global parameter. Hence, a hidden service + can no longer adjust how many introduction points it uses, or select the + nodes that will serve as its introduction points. + + While bad, we don't consider this a major drawback since we don't believe + that introduction points are a significant bottleneck on hidden services + performance. + + However, our system significantly impacts the way some load balancing + schemes for hidden services work. For example, onionbalance is a third-party + application that manages the introduction points of a hidden service in a + way that allows traffic load-balancing. This is achieved by compiling a + master descriptor that mixes and matches the introduction points of + underlying hidden service instances. + + With our system there are no descriptors that onionbalance can use to mix + and match introduction points. A variant of the onionbalance idea that could + work with our system would involve onionbalance starting a hidden service, + not establishing any intro points, and then ordering the underlying hidden + service load-balancing instances to establish intro points to all the right + introduction points. + +4.3. Behavior when introduction points go offline or misbehave + + In this new system, it's the Tor network that decides which relays should be + used as the intro points of a hidden service for every time period. This + means, that a hidden service is forced to use those relays as intro points + if it wants clients to connect to it. + + This brings up the topic of what should happen when the designated relays go + offline or refuse connections. Our behavior here should block guard + discovery attacks (as in #8239) while allowing maximum reachability for + clients. + + We should also make sure that an adversary cannot manipulate the hash ring + in such a way that forces us to rotate introduction points quickly. This is + enforced by the uptime check that is necessary for acquiring the HSDir flag + (#8243). + + For this reason we propose the following rules: + + - After every consensus and when the blinded public key changes as a result + of the time period, hidden services need to recalculate their + introduction points and adjust themselves by establishing intro points to + the new relays. + + - When an introduction point goes offline or drops connections, we attempt + to re-establish to it INTRO_RETRIES times per consensus. If the intro + point failed more than INTRO_RETRIES times for a consensus period, we + abandon it and stay with one less intro point. + + If a new consensus is released and that relay is still listed as online, + then we reset our retry counter and start trying again. + + [XXX: Is this crazy? -asn] + [XXX: INTRO_RETRIES = 3? -asn] + +4.4. Defining constants; how many introduction points for a service? + + We keep the same intro point configuration as in proposal 224. That is, each + hidden service uses 6 relays and keeps them for a whole time period. + + [XXX: Are these good constants? We don't have a chance to change them + in the future!! -asn] + [XXX: 224 makes them consensus parameters, which we can keep, but they + can still only be changed on a network-wide basis. -special] +