On Tue, Apr 8, 2014 at 4:34 PM, Roger Dingledine arma@mit.edu wrote:
On Tue, Apr 08, 2014 at 04:35:39PM +0100, mick wrote:
Moritz Bartl moritz@torservers.net allegedly wrote:
Yes. You made it generate new keys, so it is a "new relay" as far as Tor is concerned. This is why not everybody should generate new keys immediately, especially larger relays. But don't worry too much, you'll get your flags back eventually. :)
But Roger's blog post makes no mention of the advisability (or otherwise) of a mass re-generation of keys. All it says is that best practice states this would be a good idea.
The first iteration of my blog post said something like "if you run many fast and stable relays, consider spreading out your relay identity key replacement over the next week so we don't unbalance the network."
But I removed that sentence a little while later, when it became clear that nobody knows for sure but quite possibly an attacker could have extracted key material from vulnerable relays. If that actually happened, I think we probably want new identity keys asap, *especially* from the big relays, and we'll be happier tolerating a couple of bumpy days while the network recovers.
My reading, even without the PoC's and mmap docs that have since come out, is that it's always been: 1) simply connect to any vulnerable openssl 1.0.1 [START]TLS service port 2) get a nice 64k chunk of core returned to you (regardless of whether you posess any type of higher level token, onion key, user cert, etc.)
I'm not so sure it's the 'big relays' that are priority (at least as far as the net as a whole is concerned). More likely just the largest number of nodes in the shortest time. And of course key meta points like the authorities and dirservs.
I've been ad-hoc watching the resultant drop in cumulative node uptime since yesterday afternoon... we're down maybe 18% from an original ~14.1 gigasecs. And ~3000 descriptors have uptime newer than the release of openssl 1.0.1g tarball. Lots of caveats in these metrics for sure.
Ps: I liked the idea of the two key transition proposals on tor-dev. Maybe at this point, if many auths are to swap keys, point releases may be easier than coding that for now. There's also probably merit in a new rcfile called "toretcdir/authority_keys" containing the data in src/or/config.c . Would make for quicker near-term updates by distributing a small rcfile than recompiling until the proposals develop.