Part one: Facts as I understand them ------------------------------------
There are 9 directory authorities, and clients only believe a consensus networkstatus if it's signed by a majority (5) of them.
Two (moria1 and urras) of the directory authorities were unaffected by the openssl bug, and seven were affected.
Zero of the seven have generated new relay identity keys, because current clients expect them to be at their current IP:port:fingerprint and would scream in their logs and refuse to connect if the relay identity key changes.
Five of the seven have upgraded their openssl, and two (turtles and dannenberg) are offline pending an upgrade.
Three of the seven (maatuska, gabelmoo, Faravahar) have generated new directory signing keys, and four haven't yet. More specifically,
Have new signing key: maatuska old expires 2014-06-11 09:25:09 gabelmoo old expires 2015-01-11 16:26:31 Faravahar old expires 2015-01-16 03:52:30
Need new signing key: tor26 current expires 2015-02-11 17:19:09 dannenberg current expires 2014-07-17 11:10:09 turtles current expires 2014-04-20 20:01:01 dizum current expires 2014-08-12 10:18:26
So until 2014-07-17 an adversary who stole the signing keys of gabelmoo, Faravahar, tor26, dannenberg, and dizum could fabricate a convincing consensus.
I've confirmed that in fact Tor clients are happy to receive a consensus signed by old signing keys (until we've fixed #11458).
It would be a bit tricky in practice to deliver a fake consensus to clients, since they check the relay identity keys of the directory authorities if they're bootstrapping from them. But we could imagine that the same attack that got the directory signing key might get the relay identity key too. Also, clients that use evil bridges, or that have already bootstrapped and happen to go to an evil directory mirror, are other avenues for attack.
And finally, there are zero known cases of anybody extracting relay identity keys from relays using this attack. Some people have tried a bit and failed.
Part two: One way forward -------------------------
It is a leap to assume that >=5 signing keys are in the hands of the adversary, but it's also a leap to assume they're not.
Here is plan 1:
A) All seven of the vulnerable directory authorities generate new long-term authority identity keys.
B) They use their old authority identity keys as legacy signers, a la proposal 136: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/136-legacy-ke... (Remember the good old days when we had warning about horrible bugs and could design a fix beforehand?)
C) They run their new authorities on different IP:ports, with a fresh relay identity key, so as not to conflict with the old IP:ports.
D) We change the code to point to the new IP:ports:fingerprints and put out new Tor releases.
E) Authority operators run a new normal relay on the old IP:ports, using the old relay identity key, and with torrc options like FetchDirInfoExtraEarly. These relays either run sufficiently new Tor versions, or set their DirServers lines to point to the new authorities.
I haven't tried 'E' yet, and it might break horribly to have a normal relay serve all the directory authority documents. But it seems doable.
For comparison, here is plan 2:
We wait until 2014-07-17 and hope that in the mean time nobody gets attacked by the keys that surely no adversary actually has.
Anybody have a plan 3?
--Roger