[Looking for feedback] An easier way to declare families
Hello, relay operators! I'm hoping to get some feedback from relay operators, particularly those who use the MyFamily option, about the best way to deploy proposal 321. You can read the proposal at: https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/321-h... The main idea of this proposal is to provide an easier way for relays to declare that they are in the same family. With proposal 321, each relay in the same family uses a cryptographic certificate to prove that it is in the same family as the others. (That's just a summary; see the full proposal at the link above for a write up of how it works, an a description of backwards compatibility issues.) Now, my question is, how can we make this approach as usable as possible? There are several different ways that we could have it work in practice: Option 1: Every family would have a shared secret. This would be a random file that you'd have to copy to every relay in the family when you set it up. The relays would use this shared secret to derive a shared private key. If this file is ever exposed (for example, if a relay is compromised), you'd need to make a new one, and copy it to every relay in the family. (Otherwise, an attacker could claim to be in your family.) We could provide a convenient function to make a new secure shared secret, something like: $ tor --new-family-secret <filename> Option 2: As above, except instead of the shared secret, it would be a shared ed25519 private key for the family. This would be an ed25519 private key that would have to be copied to every relay in the family. If this key is ever exposed (For example, if one relay in the family is compromised), you'll need to make a new one, and copy it to every relay in the family. (Otherwise, an attacker could claim to be in your family.) We'd provide a command to generate new keys; it would look something like: $ tor --new-family-key <keyfile> Option 3: Offline certificate generation with separate distribution. In this scheme, there would be an ed25519 private key for the family, but you wouldn't have to copy it to the relays. Instead, you'd have to generate certificates from the private key offline, and then copy those certificates to the relays. They would have a lifetime of N days; you'd need to make new certificates every N days. If a relay's certificate is exposed, you don't need to generate new certificates for the other relays. You just stop generating certificates for that one relay. If the offline private key were ever exposed, you'd have to generate a new one, and a new set of certificates. The interface would probably look something like: $ tor --new-family-key <keyfile> $ tor --make-family-certs --key <keyfile> --members \ <family_list_file> --out <certfile> --lifetime <n days> Then you'd do something like: $ for member in $(cat family_hostnames); do scp <certfile> member:/srv/tor/tor-family-cert done Option 3 requires regular updates to all the relays in the family, which makes it cumbersome. Its advantage is that if a relay is compromised, you don't need to re-key the family. Options 1 and 2 are less secure, since you have to re-key your whole family if the key is ever compromised. But they have the advantage that they don't take any maintenance in the regular case. Option 1 is a little more convenient than option 2, since you can use any old random file. But that makes it more error prone: if somebody chooses an insecure password as their random file, an attacker could guess it and become a family member. So... If all three of these options were available, which of these would you choose? Is there anything else that we could do to make this system simpler or easier to use? If I'm left to my own devices, I will probably just implement option 2 for now, but leave the door open for option 3 in the future. best wishes, -- Nick
On Sat, Nov 6, 2021 at 10:36 AM Nick Mathewson <nickm@torproject.org> wrote:
Hello, relay operators!
I'm hoping to get some feedback from relay operators, particularly those who use the MyFamily option, about the best way to deploy proposal 321. You can read the proposal at:
https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/321-h...
The main idea of this proposal is to provide an easier way for relays to declare that they are in the same family. With proposal 321, each relay in the same family uses a cryptographic certificate to prove that it is in the same family as the others.
One small clarification, since I know not everybody will read the proposal: this proposal is not only for making families easier to declare: it will also make them far more efficient to implement by saving significant amounts of bandwidth for client directory downloads. So even if everybody thinks that the current MyFamily configuration mechanism is perfectly easy and hassle-free (ha), we'd still probably want to implement something like this in order to make the network more efficient. cheers, -- Nick
Nick Mathewson <nickm@torproject.org> wrote:
On Sat, Nov 6, 2021 at 10:36 AM Nick Mathewson <nickm@torproject.org> wrote:
Hello, relay operators!
I'm hoping to get some feedback from relay operators, particularly those who use the MyFamily option, about the best way to deploy proposal 321. You can read the proposal at:
https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/321-h...
The main idea of this proposal is to provide an easier way for relays to declare that they are in the same family. With proposal 321, each relay in the same family uses a cryptographic certificate to prove that it is in the same family as the others.
One small clarification, since I know not everybody will read the proposal: this proposal is not only for making families easier to declare: it will also make them far more efficient to implement by saving significant amounts of bandwidth for client directory downloads. So even if everybody thinks that the current MyFamily configuration mechanism is perfectly easy and hassle-free (ha), we'd still probably want to implement something like this in order to make the network more efficient.
Because the obvious incentive for cheaters is in the direction of trying to get clients' route selectors to choose routes through more than a single relay operated by a given cheater, rather than the other way around, this looks to me like a "solution" in search of a problem unless I am missing some special scenario. Can someone enlighten me as to why this mechanism would be needed? I.e., when and why would a cheater want his relay(s) to be included in *any* families at all? Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************
On Sun, Nov 7, 2021 at 1:36 AM Scott Bennett <bennett@sdf.org> wrote:
Because the obvious incentive for cheaters is in the direction of trying to get clients' route selectors to choose routes through more than a single relay operated by a given cheater, rather than the other way around, this looks to me like a "solution" in search of a problem unless I am missing some special scenario. Can someone enlighten me as to why this mechanism would be needed? I.e., when and why would a cheater want his relay(s) to be included in *any* families at all?
Hi, Scott! You're right that having your relay in a family means that it is less likely to be chosen, on the whole. The reason that an attacker would include their relay in a family is in order to increase the odds that, *when* they are chosen, they can observe the path. As an attacker, you wouldn't put all your relays in a given family: you'd put them in different families. As a simplified example, suppose that all relays have equal bandwidth=1. Suppose that there are N relays in the network and the attacker controls 2 of them. If the attacker does not claim membership in any family, then the probability of them seeing the first and last hop of a random circuit is `(2/N) * (1/(N-1))`. That is, one of their relays is selected for the first hop with probability 2/N, and their other one is selected with probability `1/(N-1)`. Now suppose that one of their relays claims membership in a family with F honest members, and the other claims membership in a different family with G honest members. Now the probability that they will be the first and last hop on a random circuit becomes: `(1/N) * (1/(N-1-F)) + (1/N) * (1/(N-1-G))` In other words, whenever a client picks one of the attacker's relays as a first hop, a whole family's worth of relays will be excluded when the client is choosing the last hop, which will in turn improve the attacker's odds of getting both positions. (Things would get even worse if the attacker could _define_ families or join multiple families. Suppose that one of the attacker's nodes declares family membership with every relay in the network except for one other attacker-controlled node. Then, whenever that first node was chosen, the attacker would be certain to have its other one chosen as the exit.) Now I realize that this attack is somewhat self-limiting, since it is less helpful the larger the attacker becomes. Still, because of this attack (and in case there are even better ones) it seems best to authenticate family membership. cheers, -- Nick
It is a nice surprise to see activity in this area of tor, thank you for working on this.
Option 3 requires regular updates to all the relays in the family, which makes it cumbersome. Its advantage is that if a relay is compromised, you don't need to re-key the family.
Options 1 and 2 are less secure, since you have to re-key your whole family if the key is ever compromised. But they have the advantage that they don't take any maintenance in the regular case.
Option 1 is a little more convenient than option 2, since you can use any old random file. But that makes it more error prone: if somebody chooses an insecure password as their random file, an attacker could guess it and become a family member.
I believe from an operational point of view option 1 and 2 are practically identical since most will simply use the provided tor parameter to generate the secret/key. To prevent weak random file tor could refuse to use files that are shorter than N.
If all three of these options were available, which of these would you choose? Is there anything else that we could do to make this system simpler or easier to use?
If I'm left to my own devices, I will probably just implement option 2 for now, but leave the door open for option 3 in the future.
I was about to suggest to implement option 2 and 3, so it is great to see you are considering both options. This also matches the current possibilities with OfflineMasterKey 0|1. I believe both options make sence because there are small and large families which have different levels of maturity in their tooling and operations (and different levels of risk). Smaller operators might do everything manually and are happy to use option 2, bigger probably use some form of configuration management like ansible and offlinemasterkeys already, so option 3 would basically come at no additional cost for them because they can renew family certs when they update the other certs in one go. The family certs should support the same ranges as torrc's SigningKeyLifetime. Since I maintain an ansible tor role that is used by many of the largest families: I'll certainly integrate option 3 in relayor. When compared with option 0 (current MyFamily design) option 2 has weaker properties so I would stay on option 0 until option 3 becomes available. kind regards, nusenu -- https://nusenu.github.io
On Sat, Nov 6, 2021 at 10:36 AM Nick Mathewson <nickm@torproject.org> wrote:
Hello, relay operators!
I'm hoping to get some feedback from relay operators, particularly those who use the MyFamily option, about the best way to deploy proposal 321. You can read the proposal at:
https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/321-h...
The main idea of this proposal is to provide an easier way for relays to declare that they are in the same family. With proposal 321, each relay in the same family uses a cryptographic certificate to prove that it is in the same family as the others.
(That's just a summary; see the full proposal at the link above for a write up of how it works, an a description of backwards compatibility issues.)
Now, my question is, how can we make this approach as usable as possible? There are several different ways that we could have it work in practice:
A relay operator has asked me, offline, if it is possible under this proposal for a relay to belong to more than one family. (For example, if there were two relay operators who each operated some relays on their own, but also operated some relays jointly, it might make sense to put the jointly operated relays into _both_ of the operators' families .) This is something that the proposal currently supports, but there are a couple of limitations I was wondering about: 1) The proposal currently limits each relay to no more than 3 families. Is that a reasonable upper bound? 2) We hadn't been planning to implement multi-family support right away, though I could if needed. Is that something that many operators would want? best wishes, -- Nick
On 12/14/21 17:06, Nick Mathewson wrote:
A relay operator has asked me, offline, if it is possible under this proposal for a relay to belong to more than one family. (For example, if there were two relay operators who each operated some relays on their own, but also operated some relays jointly, it might make sense to put the jointly operated relays into _both_ of the operators' families .)
Why not just consider the shared set as an own family? -- Toralf
On Tue, Dec 14, 2021 at 12:55 PM Toralf Förster <toralf.foerster@gmx.de> wrote:
On 12/14/21 17:06, Nick Mathewson wrote:
A relay operator has asked me, offline, if it is possible under this proposal for a relay to belong to more than one family. (For example, if there were two relay operators who each operated some relays on their own, but also operated some relays jointly, it might make sense to put the jointly operated relays into _both_ of the operators' families .)
Why not just consider the shared set as an own family?
The theory is that, if either operator's infrastructure were compromised or hostile, they would be a danger both to their own relays and to the shared relays. Thus, you wouldn't want to use a shared relay in the same circuit with _either_ operator's non-shared relays, but it would be okay to use either one of operator's relays in the same circuit with one of the other operator's relays. And that maps to a situation where each operator has their own relay family, and the shared relays would belong to both families. cheers, -- Nick
Nick Mathewson:
1) The proposal currently limits each relay to no more than 3 families. Is that a reasonable upper bound?
Yes, 3 is a reasonable limit.
2) We hadn't been planning to implement multi-family support right away, though I could if needed. Is that something that many operators would want?
I believe it is a rarely used feature, but we could do some analysis to see how many use it currently. Will the new family design with its bridge support be part of tor 0.4.7.x ? -- https://nusenu.github.io
On Tue, Dec 14, 2021 at 1:07 PM nusenu <nusenu-lists@riseup.net> wrote:
Nick Mathewson:
1) The proposal currently limits each relay to no more than 3 families. Is that a reasonable upper bound?
Yes, 3 is a reasonable limit.
2) We hadn't been planning to implement multi-family support right away, though I could if needed. Is that something that many operators would want?
I believe it is a rarely used feature, but we could do some analysis to see how many use it currently.
Will the new family design with its bridge support be part of tor 0.4.7.x ?
I don't think so; we haven't started implementing it yet, and we're trying not to put any more stuff into 0.4.7.x except for what we need for improved congestion-control support.
participants (5)
-
Nick Mathewson -
nusenu -
Scott Bennett -
Stefan Leibfarth -
Toralf Förster