[tor-relays] upcoming directory authority changes

[Roger Dingledine <arma@xxxxxxxxxxxxxx>]

Hello fellow relay operators,

Later today (Tuesday) we plan to do a synchronized shift where we
make two configuration changes on the directory authorities. The goal
will be to make these changes while maintaining the right threshold of
signatures so relays and users still get a safe network status consensus
that they trust.

For background, Tor uses a threshold consensus design, where as long as
a majority of directory authorities are behaving properly, all users get
the same accurate view of the Tor network. You can learn more about the
design in the bottom half of
https://support.torproject.org/about/key-management/.

Specifically, we plan to make these changes:

(1) Temporarily remove Faravahar from the set of directory authorities,
until Sina finds a new good home for it. We weren't all comfortable with
its previous hosting location inside Team Cymru's network (see the bottom
of https://blog.torproject.org/role-tor-project-board-conflicts-interest/
for more details), so to be extra safe we are making it no longer
participate in the consensus process until it is reborn in its future
home. You can read more about Sina and why we are excited to keep him
involved in the Tor community at
https://blog.torproject.org/volunteer-spotlight-sina-rabbani-helps-activists-avoid-government-censorship/.

(2) Rotate to fresh identity keys for moria1, the directory authority
that I run. In early November 2022 there was a remote break-in to the
computer running moria1. Based on the evidence and the type of attack,
I believe it was a standard automated attack -- that is, I think they
weren't targeting the directory authority and also they never realized it
*was* a directory authority. But to be extra safe, we decided to rotate
to a fresh set of keys. I was also in the middle of a planned move to
better hardware, so overall it was good timing for a fresh new start.

I should note that for both moria1 and Faravahar, we have no evidence
of any misuse of their keys. But more importantly, the threshold
consensus design keeps Tor users safe *even if* we are underestimating
what happened. Tor users and relays demand a consensus signed by a
majority of the directory authorities, and right now that's five out of
eight. Tor's security/privacy/anonymity properties remained safe before,
during, and after these changes.

Some closing thoughts and details:

* We actually already removed Faravahar in the Tor git repository and
in the Tor release 0.4.7.11 (which came out Nov 10 and has been in
Tor Browser since Nov 22), so modern clients and relays are already
demanding signatures from five authorities that aren't Faravahar. The
change we'll do today is to make the other directory authorities stop
incorporating its vote and signature into the consensus. Doing these
changes at different times opened the window for surprising but harmless
log warnings like https://bugs.torproject.org/tpo/core/tor/40725. We
could see similar issues with the new moria1 key, and if so they should
go away once there's a new release with the new key and you have upgraded.

* In my opinion there is a good argument for every directory authority
making fresh keys every few years anyway, especially in a world with
sophisticated attackers who might try to obtain keys and not leave any
traces. So for example when we bring Faravahar back I think it should
be with entirely new keys.

* Secure consensus designs have become much better in the past decade,
in large part from all the Bitcoin enthusiasm. Our current design was
always intended to be a placeholder until we got something better. And
our friends in the PETS research community have been exploring edge
cases where evil directory authorities can create mischief even when
they're slightly less than a full majority. So while we're triaging
the usual fires and priorities, we shouldn't forget about improving the
directory design.

* Directory authority keys already have a notion of an offline long-term
identity with shorter-lifetime online keys that expire periodically,
with the goal of limiting the future impact of a compromise. But it seems
like this role separation never quite matches up well to the security
issues that arise in practice, whereas it definitely adds complexity
both to the design and to operation. This piece of the design could use
some new ideas.

* Lastly, the directory authority operator community is a community too,
and the security of the Tor network relies on social trust and cooperation
between these fine people. We used to have directory authority operator
meetups in person at security conferences and at Tor dev meetings, to
maintain the social and community connections. Covid put a stop to that
along with so many other things, and we should work to bring it back. We
could start by encouraging directory authority operators to participate
in the monthly virtual relay operator meetups.

Thanks for reading all the way to the end / hope this level of detail helps,
--Roger

_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays