[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/master] Add 252-single-onion.txt proposal
commit 10a0965449ded4a589c822bc4c214cfd3a928353
Author: David Goulet <dgoulet@xxxxxxxxx>
Date: Fri Sep 4 16:58:11 2015 +0200
Add 252-single-onion.txt proposal
Signed-off-by: David Goulet <dgoulet@xxxxxxxxx>
---
proposals/000-index.txt | 2 +
proposals/252-single-onion.txt | 258 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 260 insertions(+)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index f00f3f0..fc10cce 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -172,6 +172,7 @@ Proposals by number:
249 Allow CREATE cells with >505 bytes of handshake data [DRAFT]
250 Random Number Generation During Tor Voting [DRAFT]
251 Padding for netflow record resolution reduction [DRAFT]
+252 Single Onion Services [DRAFT]
Proposals by status:
@@ -203,6 +204,7 @@ Proposals by status:
249 Allow CREATE cells with >505 bytes of handshake data
250 Random Number Generation During Tor Voting
251 Padding for netflow record resolution reduction
+ 252 Single Onion Services
NEEDS-REVISION:
131 Help users to verify they are using Tor
190 Bridge Client Authorization Based on a Shared Secret
diff --git a/proposals/252-single-onion.txt b/proposals/252-single-onion.txt
new file mode 100644
index 0000000..f91acb3
--- /dev/null
+++ b/proposals/252-single-onion.txt
@@ -0,0 +1,258 @@
+Filename: 252-single-onion.txt
+Title: Single Onion Services
+Author: John Brooks, Paul Syverson, Roger Dingledine
+Created: 2015-07-13
+Status: Draft
+
+1. Overview
+
+ Single onion services are a modified form of onion services, which trade
+ service-side location privacy for improved performance, reliability, and
+ scalability.
+
+ Single onion services have a .onion address identical to any other onion
+ service. The descriptor contains information sufficient to do a relay
+ extend of a circuit to the onion service and to open a stream for the onion
+ address. The introduction point and rendezvous protocols are bypassed for
+ these services.
+
+ We also specify behavior for a tor instance to publish a single onion
+ service, which requires a reachable OR port, without necessarily acting
+ as a public relay in the network.
+
+2. Motivation
+
+ Single onion services have a few benefits over double onion services:
+
+ * Connection latency is much lower by skipping rendezvous
+ * Stream latency is reduced on a 4-hop circuit
+ * Removing rendezvous circuits improves service scalability
+ * A single onion service can use multiple relays for load balancing
+
+ Single onion services are not location hidden on the service side,
+ but clients retain all of the benefits and privacy of onion
+ services. More details, relation to double onion services, and the
+ rationale for the 'single' and 'double' nomenclature are further
+ described in section 7.4.
+
+ We believe these improvements, along with the other benefits of onion
+ services, will be a significant incentive for website and other internet
+ service operators to provide these portals to preserve the privacy of their
+ users.
+
+3. Onion descriptors
+
+ The onion descriptor format is extended to add:
+
+ "service-extend-locations" NL encrypted-string
+ [At most once]
+
+ A list of relay extend info, which is used instead of introduction
+ points and rendezvous for single onion services. This field is
+ encoded and optionally encrypted in the same way as the
+ "introduction-points" field.
+
+ The encoded contents of this field contains no more than 10 entries,
+ each containing the following data:
+
+ "service-extend-location" SP link-specifiers NL
+ [At start, exactly once]
+ link-specifiers is a base64 encoded link specifier block, in
+ the format described by proposal 224 [BUILDING-BLOCKS] and the
+ EXTEND2 cell.
+
+ "onion-key" SP key-type NL onion-key
+ [Exactly once]
+ Describes the onion key that must be used when extending to the
+ single onion service relay.
+
+ The key-type field is one of:
+ "tap"
+ onion-key is a PEM-encoded RSA relay onion key
+ "ntor"
+ onion-key is a base64-encoded NTOR relay onion key
+
+ [XXX: Should there be some kind of cookie to prove that we have the desc?
+ See also section 7.1. -special]
+
+ A descriptor may contain either or both of "introduction-points" and
+ "service-extend-locations"; see section 5.2.
+
+ [XXX: What kind of backwards compatibility issues exist here? Will existing
+ relays accept one of those descriptors? -special]
+
+4. Reaching a single onion service as a client
+
+ Single onion services use normal onion hostnames, so the client will first
+ request the service's descriptor. If the descriptor contains a
+ "service-extend-locations" field, the client should ignore the introduction
+ points and rendezvous process in favor of the process defined here.
+
+ The descriptor's "service-extend-locations" information is sufficient for a
+ client to extend a circuit to the onion service, regardless of whether it
+ is also listed as a relay in the network consensus. This extend info must
+ not be used for any other purpose. If multiple extend locations are
+ specified, the client should randomly select one.
+
+ The client uses a 3-hop circuit to extend to the service location from the
+ descriptor. Once this circuit is built, the client sends a BEGIN cell to
+ the relay, with the onion address as hostname and the desired TCP port.
+
+ If the circuit or stream fails, the client should retry using another
+ extend location from the descriptor. If all extend locations fail, and the
+ descriptor contains an "introduction-points" field, the client may fall
+ back to a full rendezvous operation.
+
+5. Publishing a single onion service
+
+ To act as a single onion service, a tor instance (or cooperating group of
+ tor instances) must:
+
+ * Have a publicly accessible OR port
+ * Publish onion descriptors in the same manner as any onion service
+ * Include a "service-extend-locations" section in the onion descriptor
+ * Accept RELAY_BEGIN cells for the service as defined in section 5.3
+
+5.1. Configuration options
+
+ The tor server operating a single onion service must accept connections as
+ a tor relay, but is not required to be published in the consensus or to
+ allow extending circuits. To enable this, we propose the following
+ configuration option:
+
+ RelayAllowExtend 0|1
+ If set, allow clients to extend circuits from this relay. Otherwise,
+ refuse all extend cells. PublishServerDescriptor must also be disabled
+ if this option is disabled. If ExitRelay is also disabled, this relay
+ will not pass through any traffic.
+
+5.2. Publishing descriptors
+
+ A single onion service must publish descriptors in the same manner as any
+ onion service, as defined by rend-spec and section 3 of this proposal.
+
+ Optionally, a set of introduction points may be included in the descriptor
+ to provide backwards compatibility with clients that don't support single
+ onion services, or to provide a fallback when the extend locations fail.
+
+5.3. RELAY_BEGIN
+
+ When a RELAY_BEGIN cell is received with a configured single onion hostname
+ as the destination, the stream should be connected to the configured
+ backend server in the same manner as a service-side rendezvous stream.
+
+ All relays must reject any RELAY_BEGIN cell with an address ending in
+ ".onion" that does not match a locally configured single onion service.
+
+6. Other considerations
+
+6.1. Load balancing
+
+ High capacity services can distribute load by including multiple entries in
+ the "service-extend-locations" section of the descriptor, or by publishing
+ several descriptors to different onion service directories, or by a
+ combination of these methods.
+
+6.2. Benefits of also running a Tor relay
+
+ If a single onion service also acts as a published tor relay, it will keep
+ connections to many other tor relays. This can significantly reduce the
+ latency of connections to the single onion service, and also helps the tor
+ network.
+
+6.3. Proposal 224 ("Next-Generation Hidden Services")
+
+ This proposal is compatible with proposal 224, with small changes to the
+ service descriptor format. In particular:
+
+ The "service-extend-location" sections are included in the encrypted
+ portion of the descriptor, adjacent to any "introduction-point" sections.
+ The "service-extend-locations" field is no longer present. An onion service
+ is also single onion service if any "service-extend-location" field is
+ present.
+
+6.4. Proposal 246 ("Merging Hidden Service Directories and Intro Points")
+
+ This proposal is compatible with proposal 246. The onion service will
+ publish its descriptor to the introduction points in the same manner as any
+ other onion service. The client may choose to build a circuit to the
+ specified relays, or to continue with the rendezvous protocol.
+
+ The client should not extend from the introduction point to the single
+ onion service's relay, to avoid overloading the introduction point. The
+ client may truncate the circuit and extend through a new relay.
+
+7. Discussion
+
+7.1. Authorization
+
+ Client authorization for a single onion service is possible through
+ encryption of the service-extend-locations section in the descriptor, or
+ "stealth" publication under a new onion address, as with traditional onion
+ services.
+
+ One problem with this is that if you suspect a relay is also serving a
+ single onion service, you can connect to it and send RELAY_BEGIN without
+ any further authorization. To prevent this, we would need to include a
+ cookie from the descriptor in the RELAY_BEGIN information.
+
+7.2. Preventing relays from being unintentionally published
+
+ Many single onion servers will not want to relay other traffic, and will
+ set 'PublishServerDescriptor 0' to prevent it. Even when they do, they will
+ still generate a relay descriptor, which could be downloaded and published
+ to a directory authority without the relay's consent. To prevent this, we
+ should insert a field in the relay descriptor when PublishServerDescriptor
+ is disabled that instructs relays to never include it as part of a
+ consensus.
+
+ [XXX: Also see task #16564]
+
+7.3. Ephemeral single onion services (ADD_ONION)
+
+ The ADD_ONION control port command could be extended to support ephemerally
+ configured single onion services. We encourage this, but specifying its
+ behavior is out of the scope of this proposal.
+
+7.4. Onion service taxonomy and nomenclature
+
+ Onion services in general provide several benefits. First, by requiring a
+ connection via Tor they provide the client the protections of Tor and make
+ it much more difficult to inadvertently bypass those protections than when
+ connecting to a non .onion site. Second, because .onion addresses are
+ self-authenticating, onion services have look-up, routing, and
+ authentication protections not provided by sites with standard domain
+ addresses. These benefits apply to all onion services.
+
+ Onion services as originally introduced also provide network location
+ hiding of the service itself: because the client only ever connects through
+ the end of a Tor circuit created by the onion service, the IP address of
+ the onion service also remains protected.
+
+ Applications and services already exist that use existing onion service
+ protocols for the above described general benefits without the need for
+ network location hiding. This Proposal is accordingly motivated by a desire
+ to provide the general benefits, without the complexity and overhead of
+ also protecting the location of the service.
+
+ Further, as with what had originally been called 'location hidden
+ services', there may be useful and valid applications of this design that
+ are not reflected in our current intent. Just as 'location hidden service'
+ is a misleading name for many current onion service applications, we prefer
+ a name that is descriptive of the system but flexible with respect to
+ applications of it. We also prefer a nomenclature that consistently works
+ for the different types of onion services.
+
+ It is also important to have short, simple names lest usage efficiencies
+ evolve easier names for us. For example, 'hidden service' has replaced the
+ original 'location hidden service' in Tor Proposals and other writings.
+
+ For these reasons, we have chosen 'onion services' to refer to both those
+ as set out in this Proposal and those with the client-side and server-side
+ protections of the original---also for referring indiscriminately to any
+ and all onion services. We use 'double-onion service' to refer to services
+ that join two Tor circuits, one from the server and one from the client. We
+ use 'single-onion' when referring to services that use only a client-side
+ Tor circuit. In speech we sometimes use the even briefer, 'two-nion' and
+ 'one-ion' respectively.
+
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits