torproject/torspec
1
0
Fork 0
mirror of https://github.com/torproject/torspec.git synced 2025-03-03 14:18:28 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

fix line endings on prop 307

Browse Source 
(whoever committed it, committed it with a bonus ^M on each line)
This commit is contained in:
Roger Dingledine 2019-12-13 15:44:44 -05:00
parent a51495cdd7
commit 54346bf40f
1 changed files with 182 additions and 182 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

364
proposals/307-onionbalance-v3.txt
View File

@ -1,182 +1,182 @@
Filename: 307-onionbalance-v3.txt Filename: 307-onionbalance-v3.txt
Title: Onion Balance Support for Onion Service v3 Title: Onion Balance Support for Onion Service v3
Author: Nick Mathewson Author: Nick Mathewson
Created: 03-April-2019 Created: 03-April-2019
Status: Draft Status: Draft
0. Draft Notes 0. Draft Notes
2019-07-25: 2019-07-25:
At this point in time, the cross-certification is not implemented At this point in time, the cross-certification is not implemented
correctly in >= tor-0.3.2.1-alpha. See https://trac.torproject.org/29583 correctly in >= tor-0.3.2.1-alpha. See https://trac.torproject.org/29583
for more details. for more details.
This proposal assumes that this bug is fixed. This proposal assumes that this bug is fixed.
1. Introduction 1. Introduction
The OnionBalance tool allows several independent Tor instances to host an The OnionBalance tool allows several independent Tor instances to host an
onion service, while clients can access that onion service without having onion service, while clients can access that onion service without having
to take its distributed status into account. OnionBalance works by having to take its distributed status into account. OnionBalance works by having
each instance run a separate onion service. Then, a management server each instance run a separate onion service. Then, a management server
periodically downloads the descriptors from those onion services, and periodically downloads the descriptors from those onion services, and
generates a new descriptor containing the introduction points from each generates a new descriptor containing the introduction points from each
instance's onion service. instance's onion service.
OnionBalance is used by several high-profile onion services, including OnionBalance is used by several high-profile onion services, including
Facebook and The Tor Project. Facebook and The Tor Project.
Unfortunately, because of the cross-certification features in v3 onion Unfortunately, because of the cross-certification features in v3 onion
services, OnionBalance no longer works for them. To a certain extent, this services, OnionBalance no longer works for them. To a certain extent, this
breakage is because of a security improvement: It's probably a good thing breakage is because of a security improvement: It's probably a good thing
that random third parties can no longer grab a onion service's introduction that random third parties can no longer grab a onion service's introduction
points and claim that they are introduction points for a different service. points and claim that they are introduction points for a different service.
But nonetheless, a lack of a working OnionBalance remains an obstacle for But nonetheless, a lack of a working OnionBalance remains an obstacle for
v3 onion service migration. v3 onion service migration.
This proposal describes extensions to v3 onion service design to This proposal describes extensions to v3 onion service design to
accommodate OnionBalance. accommodate OnionBalance.
2. Background and Solution 2. Background and Solution
If an OnionBalance management server wants to provide an aggregate If an OnionBalance management server wants to provide an aggregate
descriptor for a v3 onion service, it faces several obstacles that it descriptor for a v3 onion service, it faces several obstacles that it
didn't have in v2. didn't have in v2.
When the management server goes to construct an aggregated descriptor, it When the management server goes to construct an aggregated descriptor, it
will have a mismatch on the "auth-key", "enc-key-cert", and will have a mismatch on the "auth-key", "enc-key-cert", and
"legacy-key-cert" fields: these fields are supposed to certify the onion "legacy-key-cert" fields: these fields are supposed to certify the onion
service's current descriptor-signing key, but each of these keys will be service's current descriptor-signing key, but each of these keys will be
generated independently by each instance. Because they won't match each generated independently by each instance. Because they won't match each
other, there is no possible key that the aggregated descriptor could use other, there is no possible key that the aggregated descriptor could use
for its descriptor signing key. for its descriptor signing key.
In this design, we require that each instance should know in advance about In this design, we require that each instance should know in advance about
a descriptor-signing public key that the aggregate descriptor will use for a descriptor-signing public key that the aggregate descriptor will use for
each time period. (I'll explain how they can do this later, in section 3 each time period. (I'll explain how they can do this later, in section 3
below.) They don't have to know the corresponding private key. below.) They don't have to know the corresponding private key.
When generating their own onion service descriptors for a given time When generating their own onion service descriptors for a given time
period, the instances generate these additional fields to be used for the period, the instances generate these additional fields to be used for the
aggregate descriptor: aggregate descriptor:
"meta-auth-key" "meta-auth-key"
"meta-enc-key-cert" "meta-enc-key-cert"
"meta-legacy-key-cert" "meta-legacy-key-cert"
These fields correspond to "auth-key", "enc-key-cert", and These fields correspond to "auth-key", "enc-key-cert", and
"legacy-key-cert" respectively, but differ in one regard: the "legacy-key-cert" respectively, but differ in one regard: the
descriptor-signing public key that they certify is _not_ the instance's own descriptor-signing public key that they certify is _not_ the instance's own
descriptor-signing key, but rather the aggregate public key for the time descriptor-signing key, but rather the aggregate public key for the time
period. period.
Ordinary clients ignore these new fields. Ordinary clients ignore these new fields.
When the management server creates the aggregate descriptor, it checks that When the management server creates the aggregate descriptor, it checks that
the signing key for each of these "meta" fields matches the signing key for the signing key for each of these "meta" fields matches the signing key for
its corresponding non-"meta" field, and that they certify the correct its corresponding non-"meta" field, and that they certify the correct
descriptor-signing key-- and then uses these fields in place of their descriptor-signing key-- and then uses these fields in place of their
corresponding non-"meta" variants. corresponding non-"meta" variants.
2.1. A quick note on synchronization 2.1. A quick note on synchronization
In the design above, and in the section below, I frequently refer to "the In the design above, and in the section below, I frequently refer to "the
current time period". By this, I mean the time period for which the current time period". By this, I mean the time period for which the
descriptor is encoded, not the time period in which it is generated. descriptor is encoded, not the time period in which it is generated.
Instances and management servers should generate descriptors for the two Instances and management servers should generate descriptors for the two
closest time periods, as they do today: no additional synchronization closest time periods, as they do today: no additional synchronization
should needed here. should needed here.
3. How to distribute descriptor-signing keys 3. How to distribute descriptor-signing keys
The design requires that every instance of the onion service knows about The design requires that every instance of the onion service knows about
the public descriptor-signing key that will be used for the aggregate onion the public descriptor-signing key that will be used for the aggregate onion
service. Here I'll discuss how this can be achieved. service. Here I'll discuss how this can be achieved.
3.1. If the instances are trusted. 3.1. If the instances are trusted.
If the management server trusts each of the instances, it can distribute a If the management server trusts each of the instances, it can distribute a
shared secret to each one of them, and use this shared secret to derive shared secret to each one of them, and use this shared secret to derive
each time period's private key. each time period's private key.
For example, if the shared secret is SK, then the private descriptor- For example, if the shared secret is SK, then the private descriptor-
signing key for each time period could be derived as: signing key for each time period could be derived as:
H("meta-descriptor-signing-key-deriv" | H("meta-descriptor-signing-key-deriv" |
onion_service_identity onion_service_identity
INT_8(period_num) | INT_8(period_num) |
INT_8(period_length) | INT_8(period_length) |
SK ) SK )
(Remember that in the terminology of rend-spec-v3, INT_8() denotes a 64-bit (Remember that in the terminology of rend-spec-v3, INT_8() denotes a 64-bit
integer, see section 0.2 in rend-spec-v3.txt.) integer, see section 0.2 in rend-spec-v3.txt.)
If shared secret is ever compromised, then an attacker can impersonate the If shared secret is ever compromised, then an attacker can impersonate the
onion service until the shared secret is changed, and can correlate all onion service until the shared secret is changed, and can correlate all
past descriptors for the onion service. past descriptors for the onion service.
3.2. If the instances are not trusted: Option One 3.2. If the instances are not trusted: Option One
If the management server does not trust the instances with If the management server does not trust the instances with
descriptor-signing public keys, another option for it is to simply descriptor-signing public keys, another option for it is to simply
distribute a load of public keys in advance, and use them according to a distribute a load of public keys in advance, and use them according to a
schedule. schedule.
In this design, the management server would pre-generate the In this design, the management server would pre-generate the
"descriptor-signing-key-cert" fields for a long time in advance, and "descriptor-signing-key-cert" fields for a long time in advance, and
distribute them to the instances offline. Each one would be distribute them to the instances offline. Each one would be
associated with its corresponding time period. associated with its corresponding time period.
If these certificates were revealed to an attacker, the attacker If these certificates were revealed to an attacker, the attacker
could correlate descriptors for the onion service with one another, could correlate descriptors for the onion service with one another,
but could not impersonate the service. but could not impersonate the service.
3.3. If the instances are not trusted: Option Two 3.3. If the instances are not trusted: Option Two
Another option for the trust model of 3.2 above is to use the same Another option for the trust model of 3.2 above is to use the same
key-blinding method as used for v3 onion services. The management server key-blinding method as used for v3 onion services. The management server
would hold a private descriptor-signing key, and use it to derive a would hold a private descriptor-signing key, and use it to derive a
different private descriptor-signing key for each time period. The instance different private descriptor-signing key for each time period. The instance
servers would hold the corresponding public key, and use it to derive a servers would hold the corresponding public key, and use it to derive a
different public descriptor-signing key for each time period. different public descriptor-signing key for each time period.
(For security, the key-blinding function in this case should use a (For security, the key-blinding function in this case should use a
different nonce than used in the) different nonce than used in the)
This design would allow the instances to only be configured once, which This design would allow the instances to only be configured once, which
would be simpler than 3.2 above-- but at a cost. The management server's would be simpler than 3.2 above-- but at a cost. The management server's
use of a long-term private descriptor-signing key would require it to keep use of a long-term private descriptor-signing key would require it to keep
that key online. (It could keep the derived private descriptor-signing keys that key online. (It could keep the derived private descriptor-signing keys
online, but the parent key could be derived from them.) online, but the parent key could be derived from them.)
Here, if the instance's knowledge were revealed to an attack, the attacker Here, if the instance's knowledge were revealed to an attack, the attacker
could correlate descriptors for the onion service with one another, but could correlate descriptors for the onion service with one another, but
could not impersonate the service. could not impersonate the service.
4. Some features of this proposal 4. Some features of this proposal
We retain the property that each instance service remains accessible as a We retain the property that each instance service remains accessible as a
working onion service. However, anyone who can access it can identify it as working onion service. However, anyone who can access it can identify it as
an instance of an OnionBalance service, and correlate its descriptor to the an instance of an OnionBalance service, and correlate its descriptor to the
aggregate descriptor. aggregate descriptor.
Instances could use client authorization to ensure that only the management Instances could use client authorization to ensure that only the management
server can decrypt their introduction points. However, because of the server can decrypt their introduction points. However, because of the
key-blinding features of v3 onion services, nobody who doesn't know the key-blinding features of v3 onion services, nobody who doesn't know the
onion addresses for the instances can access them anyway: It would be onion addresses for the instances can access them anyway: It would be
sufficient to keep these addresses secret. sufficient to keep these addresses secret.
Although anybody who successfully accesses an instance can correlate its Although anybody who successfully accesses an instance can correlate its
descriptor to the meta-descriptor, this only works for two descriptors descriptor to the meta-descriptor, this only works for two descriptors
within a single time period: You can't match an instance descriptor from within a single time period: You can't match an instance descriptor from
one time period to a meta-descriptor from another. one time period to a meta-descriptor from another.
A. Acknowledgments A. Acknowledgments
Thanks to the network team for helping me clarify my ideas here, explore Thanks to the network team for helping me clarify my ideas here, explore
options, and better understand some of the implementations and challenges options, and better understand some of the implementations and challenges
in this problem space. in this problem space.
This research was supported by NSF grants CNS-1526306 and CNS-1619454. This research was supported by NSF grants CNS-1526306 and CNS-1619454.