commit 54346bf40f5509505f154d6137370ee882522920 Author: Roger Dingledine arma@torproject.org Date: Fri Dec 13 15:44:44 2019 -0500
fix line endings on prop 307
(whoever committed it, committed it with a bonus ^M on each line) --- proposals/307-onionbalance-v3.txt | 364 +++++++++++++++++++------------------- 1 file changed, 182 insertions(+), 182 deletions(-)
diff --git a/proposals/307-onionbalance-v3.txt b/proposals/307-onionbalance-v3.txt index 6ff0ca4..9a66c69 100644 --- a/proposals/307-onionbalance-v3.txt +++ b/proposals/307-onionbalance-v3.txt @@ -1,182 +1,182 @@ -Filename: 307-onionbalance-v3.txt -Title: Onion Balance Support for Onion Service v3 -Author: Nick Mathewson -Created: 03-April-2019 -Status: Draft - -0. Draft Notes - - 2019-07-25: - - 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 - for more details. - - This proposal assumes that this bug is fixed. - -1. Introduction - - The OnionBalance tool allows several independent Tor instances to host an - onion service, while clients can access that onion service without having - to take its distributed status into account. OnionBalance works by having - each instance run a separate onion service. Then, a management server - periodically downloads the descriptors from those onion services, and - generates a new descriptor containing the introduction points from each - instance's onion service. - - OnionBalance is used by several high-profile onion services, including - Facebook and The Tor Project. - - Unfortunately, because of the cross-certification features in v3 onion - 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 - 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. - But nonetheless, a lack of a working OnionBalance remains an obstacle for - v3 onion service migration. - - This proposal describes extensions to v3 onion service design to - accommodate OnionBalance. - -2. Background and Solution - - If an OnionBalance management server wants to provide an aggregate - descriptor for a v3 onion service, it faces several obstacles that it - didn't have in v2. - - When the management server goes to construct an aggregated descriptor, it - will have a mismatch on the "auth-key", "enc-key-cert", and - "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 - generated independently by each instance. Because they won't match each - other, there is no possible key that the aggregated descriptor could use - for its descriptor signing key. - - 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 - 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. - - When generating their own onion service descriptors for a given time - period, the instances generate these additional fields to be used for the - aggregate descriptor: - - "meta-auth-key" - "meta-enc-key-cert" - "meta-legacy-key-cert" - - These fields correspond to "auth-key", "enc-key-cert", and - "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 key, but rather the aggregate public key for the time - period. - - Ordinary clients ignore these new fields. - - 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 - its corresponding non-"meta" field, and that they certify the correct - descriptor-signing key-- and then uses these fields in place of their - corresponding non-"meta" variants. - -2.1. A quick note on synchronization - - 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 - descriptor is encoded, not the time period in which it is generated. - - Instances and management servers should generate descriptors for the two - closest time periods, as they do today: no additional synchronization - should needed here. - -3. How to distribute descriptor-signing keys - - 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 - service. Here I'll discuss how this can be achieved. - -3.1. If the instances are trusted. - - 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 - each time period's private key. - - For example, if the shared secret is SK, then the private descriptor- - signing key for each time period could be derived as: - - H("meta-descriptor-signing-key-deriv" | - onion_service_identity - INT_8(period_num) | - INT_8(period_length) | - SK ) - - (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.) - - If shared secret is ever compromised, then an attacker can impersonate the - onion service until the shared secret is changed, and can correlate all - past descriptors for the onion service. - -3.2. If the instances are not trusted: Option One - - If the management server does not trust the instances with - 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 - schedule. - - In this design, the management server would pre-generate the - "descriptor-signing-key-cert" fields for a long time in advance, and - distribute them to the instances offline. Each one would be - associated with its corresponding time period. - - If these certificates were revealed to an attacker, the attacker - could correlate descriptors for the onion service with one another, - but could not impersonate the service. - -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 - 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 - different private descriptor-signing key for each time period. The instance - servers would hold the corresponding public key, and use it to derive a - different public descriptor-signing key for each time period. - - (For security, the key-blinding function in this case should use a - different nonce than used in the) - - 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 - 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 - online, but the parent key could be derived from them.) - - 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 not impersonate the service. - -4. Some features of this proposal - - 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 - an instance of an OnionBalance service, and correlate its descriptor to the - aggregate descriptor. - - Instances could use client authorization to ensure that only the management - server can decrypt their introduction points. However, because of 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 - sufficient to keep these addresses secret. - - Although anybody who successfully accesses an instance can correlate its - descriptor to the meta-descriptor, this only works for two descriptors - within a single time period: You can't match an instance descriptor from - one time period to a meta-descriptor from another. - -A. Acknowledgments - - Thanks to the network team for helping me clarify my ideas here, explore - options, and better understand some of the implementations and challenges - in this problem space. - - This research was supported by NSF grants CNS-1526306 and CNS-1619454. +Filename: 307-onionbalance-v3.txt +Title: Onion Balance Support for Onion Service v3 +Author: Nick Mathewson +Created: 03-April-2019 +Status: Draft + +0. Draft Notes + + 2019-07-25: + + 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 + for more details. + + This proposal assumes that this bug is fixed. + +1. Introduction + + The OnionBalance tool allows several independent Tor instances to host an + onion service, while clients can access that onion service without having + to take its distributed status into account. OnionBalance works by having + each instance run a separate onion service. Then, a management server + periodically downloads the descriptors from those onion services, and + generates a new descriptor containing the introduction points from each + instance's onion service. + + OnionBalance is used by several high-profile onion services, including + Facebook and The Tor Project. + + Unfortunately, because of the cross-certification features in v3 onion + 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 + 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. + But nonetheless, a lack of a working OnionBalance remains an obstacle for + v3 onion service migration. + + This proposal describes extensions to v3 onion service design to + accommodate OnionBalance. + +2. Background and Solution + + If an OnionBalance management server wants to provide an aggregate + descriptor for a v3 onion service, it faces several obstacles that it + didn't have in v2. + + When the management server goes to construct an aggregated descriptor, it + will have a mismatch on the "auth-key", "enc-key-cert", and + "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 + generated independently by each instance. Because they won't match each + other, there is no possible key that the aggregated descriptor could use + for its descriptor signing key. + + 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 + 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. + + When generating their own onion service descriptors for a given time + period, the instances generate these additional fields to be used for the + aggregate descriptor: + + "meta-auth-key" + "meta-enc-key-cert" + "meta-legacy-key-cert" + + These fields correspond to "auth-key", "enc-key-cert", and + "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 key, but rather the aggregate public key for the time + period. + + Ordinary clients ignore these new fields. + + 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 + its corresponding non-"meta" field, and that they certify the correct + descriptor-signing key-- and then uses these fields in place of their + corresponding non-"meta" variants. + +2.1. A quick note on synchronization + + 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 + descriptor is encoded, not the time period in which it is generated. + + Instances and management servers should generate descriptors for the two + closest time periods, as they do today: no additional synchronization + should needed here. + +3. How to distribute descriptor-signing keys + + 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 + service. Here I'll discuss how this can be achieved. + +3.1. If the instances are trusted. + + 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 + each time period's private key. + + For example, if the shared secret is SK, then the private descriptor- + signing key for each time period could be derived as: + + H("meta-descriptor-signing-key-deriv" | + onion_service_identity + INT_8(period_num) | + INT_8(period_length) | + SK ) + + (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.) + + If shared secret is ever compromised, then an attacker can impersonate the + onion service until the shared secret is changed, and can correlate all + past descriptors for the onion service. + +3.2. If the instances are not trusted: Option One + + If the management server does not trust the instances with + 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 + schedule. + + In this design, the management server would pre-generate the + "descriptor-signing-key-cert" fields for a long time in advance, and + distribute them to the instances offline. Each one would be + associated with its corresponding time period. + + If these certificates were revealed to an attacker, the attacker + could correlate descriptors for the onion service with one another, + but could not impersonate the service. + +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 + 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 + different private descriptor-signing key for each time period. The instance + servers would hold the corresponding public key, and use it to derive a + different public descriptor-signing key for each time period. + + (For security, the key-blinding function in this case should use a + different nonce than used in the) + + 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 + 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 + online, but the parent key could be derived from them.) + + 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 not impersonate the service. + +4. Some features of this proposal + + 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 + an instance of an OnionBalance service, and correlate its descriptor to the + aggregate descriptor. + + Instances could use client authorization to ensure that only the management + server can decrypt their introduction points. However, because of 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 + sufficient to keep these addresses secret. + + Although anybody who successfully accesses an instance can correlate its + descriptor to the meta-descriptor, this only works for two descriptors + within a single time period: You can't match an instance descriptor from + one time period to a meta-descriptor from another. + +A. Acknowledgments + + Thanks to the network team for helping me clarify my ideas here, explore + options, and better understand some of the implementations and challenges + in this problem space. + + This research was supported by NSF grants CNS-1526306 and CNS-1619454.