[tor-dev] Implications of openssl bug on directory authorities

[Roger Dingledine <arma@xxxxxxx>]

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-keys.txt
(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

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