<div dir="ltr">Hello, relay operators!<br><br>I'm hoping to get some feedback from relay operators, particularly<br>those who use the MyFamily option, about the best way to deploy<br>proposal 321.  You can read the proposal at:<br><br><a href="https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/321-happy-families.md">https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/321-happy-families.md</a><br><br>The main idea of this proposal is to provide an easier way for<br>relays to declare that they are in the same family.  With proposal<br>321, each relay in the same family uses a cryptographic certificate<br>to prove that it is in the same family as the others.<br><br>(That's just a summary; see the full proposal at the link above for<br>a write up of how it works, an a description of backwards<br>compatibility issues.)<br><br>Now, my question is, how can we make this approach as usable as possible?<br>There are several different ways that we could have it work in practice:<br><br>Option 1:<br><br>   Every family would have a shared secret.  This would be a<br>   random file that you'd have to copy to every relay in the family<br>   when you set it up. The relays would use this shared secret to<br>   derive a shared private key.<br><br>   If this file is ever exposed (for example, if a relay is<br>   compromised), you'd need to make a new one, and copy it to every<br>   relay in the family.  (Otherwise, an attacker could claim to be<br>   in your family.)<br><br>   We could provide a convenient function to make a new secure<br>   shared secret, something like:<br><br>      $ tor --new-family-secret <filename><br><br><br>Option 2:<br><br>   As above, except instead of the shared secret, it would be a<br>   shared ed25519 private key for the family.  This would be an<br>   ed25519 private key that would have to be copied to every relay<br>   in the family.<br><br>   If this key is ever exposed (For example, if one relay in the<br>   family is compromised), you'll need to make a new one, and copy<br>   it to every relay in the family.  (Otherwise, an attacker could<br>   claim to be in your family.)<br><br>   We'd provide a command to generate new keys; it would look<br>   something like:<br><br>      $ tor --new-family-key <keyfile><br><br><br>Option 3:<br><br>   Offline certificate generation with separate distribution.  In<br>   this scheme, there would be an ed25519 private key for the<br>   family, but you wouldn't have to copy it to the relays.  Instead,<br>   you'd have to generate certificates from the private key offline,<br>   and then copy those certificates to the relays.  They would have<br>   a lifetime of N days; you'd need to make new certificates every N<br>   days.<br><br>   If a relay's certificate is exposed, you don't need to generate<br>   new certificates for the other relays.  You just stop generating<br>   certificates for that one relay.<br><br>   If the offline private key were ever exposed, you'd have to<br>   generate a new one, and a new set of certificates.<br><br>   The interface would probably look something like:<br><br>     $ tor --new-family-key <keyfile><br>     $ tor --make-family-certs --key <keyfile> --members \<br>          <family_list_file> --out <certfile> --lifetime <n days><br><br>   Then you'd do something like:<br>     $ for member in $(cat family_hostnames); do<br>          scp <certfile> member:/srv/tor/tor-family-cert<br>       done<br><br><br><br>Option 3 requires regular updates to all the relays in the family,<br>which makes it cumbersome.  Its advantage is that if a relay is<br>compromised, you don't need to re-key the family.<br><br>Options 1 and 2 are less secure, since you have to re-key your whole<br>family if the key is ever compromised.  But they have the advantage<br>that they don't take any maintenance in the regular case.<br><br>Option 1 is a little more convenient than option 2, since you can<br>use any old random file.  But that makes it more error prone: if<br>somebody chooses an insecure password as their random file, an<br>attacker could guess it and become a family member.<br><br>So...<br><br>If all three of these options were available, which of these would<br>you choose?  Is there anything else that we could do to make this<br>system simpler or easier to use?<br><br>If I'm left to my own devices, I will probably just implement option<br><div>2 for now, but leave the door open for option 3 in the future.</div><div><br></div><div>best wishes,</div><div>-- <br></div><div>Nick<br></div></div>