Opened 9 months ago

Closed 8 months ago

Last modified 8 months ago

#19271 closed defect (implemented)

Remove urras from default_authorities

Reported by: cypherpunks Owned by:
Priority: Medium Milestone: Tor: 0.2.9.x-final
Component: Core Tor/DirAuth Version:
Severity: Normal Keywords: ioerror urras dirauth TorCoreTeam201607
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

As of this moment urras is still listed in default_authorities in
src/or/config.c.

This ticket is to consider removing it.

More broadly, does the Tor Project have a procedure for removing
dirauths, or for considering their removal?

Child Tickets

Change History (26)

comment:1 Changed 9 months ago by arma

We (the other dir auths) are considering this one internally.

(I figure I should say that here so this ticket doesn't get full of people who aren't dir auths speculating about stuff.)

comment:2 Changed 9 months ago by cypherpunks

Thanks, good to know.

What will the deliberation process look like? Will community input be considered? Is there a formal process for this? If not, I think now is the time to create one (and I think transparency is essential here).

comment:3 Changed 9 months ago by atagar

Hi cypherpunks, thanks for the tracking ticket. As Roger said we've already discussed this a little.

Directory authority changes require a tor release and as such there's no big rush. We'll likely need to find a replacement authority to keep the odd count so this will take a little thought.

comment:4 Changed 9 months ago by cypherpunks

I understand.

We'll likely need to find a replacement

What's the procedure for adding a dirauth, by the way? Is there something more than an ad-hoc vetting process?

to keep the odd count

Maybe I'm just too tired, but I count 10 entries in default_authorities. What am I missing?

comment:5 Changed 9 months ago by atagar

Bah, thought we had an entry for this on the FAQ but evidently not. :(

Roger, would you or another authority operator mind writing one?

Directory authorities are operated by folks highly known and respected within this community, with a bias toward spreading out across geographic and geopolitical boundaries (particularly with regard to its hosting location). The present authority operators will probably discuss this among themselves soon.

Maybe I'm just too tired, but I count 10 entries in default_authorities. What am I missing?

Very understandable point of confusion - this puzzles lots of folks. Tonga does not vote in the consensus (it lacks a v3ident, only being used for bootstrapping and as the bridge authority).

comment:6 Changed 9 months ago by cypherpunks

Re: Tonga--Aha, I see. Thanks.

I have read that or something substantially similar before; I just couldn't find it.

My question is a bit more specific, though: what is the ultimate process to add or remove a dirauth? Do all current dirauths vote in an IRC channel, and then someone commits the change? Is there an informal discussion and then (e.g.) Roger just commits (or not) whatever he wants? Or is it that a formal process is what you were referring to in, "The present authority operators will probably discuss this among themselves soon."?

Also, why is this all being discussed in private? I think the Tor community has a strong interest in, at the very least, visibility into the dirauth vetting/expulsion process, as well as the internal discussion about setting up that process.

Or am I wrong? Is this discussion actually being held somewhere public where I can join?

Thanks,
cypherpunks

comment:7 Changed 9 months ago by atagar

Gotcha, understandable question and one I'll need to leave to Roger and the other dirauths. :)

comment:8 Changed 9 months ago by cypherpunks

What is the rationale for removing urras? And who will run the new dirauth? I'm sure certain people would love to get their paws on one.

comment:9 Changed 9 months ago by cypherpunks

urras is the dirauth Jake runs. Of course, dirauths must be fully trusted. Recent events (which should be discussed elsewhere) have cast doubt on urras' trustworthiness. Now, I am not in any rush to kick urras out. It has been (AFAIK) well-behaved up until now, and there's a reason we have a consensus vote.

However, now is the time for the Tor Project to forumlate and publish a procedure, so in this case and in the future there is a neutral, transparent and not-so-arbitrary way to add or remove a dirauth.

I am very uncomfortable with the current procedure, which appears to be, "Current Tor Elites/dirauths meet and decide in a smoke-filled mailing list". The opacity and secrecy surrounding the dirauths--one of the most important, if not the most important, foundations of trust in Tor--worries me very much.

comment:10 Changed 9 months ago by cypherpunks

@arma @atagar

Has anything new happened in the apparently TOP SECRET discussion? The silence--about the ticket title and about the procedures--is deafening. Why is the Tor Project squandering trust like this?

comment:11 Changed 9 months ago by atagar

Nope, no new developments here. Again, there's no great rush. Maybe the dirauths will discuss it soon, or maybe it'll be deferred until the developer meeting in September. Not sure - Roger has a lot of things in the air, most of which are far more important than this.

Personally I like the idea of greater dirauth transparency but I'm not a dirauth operator, so I can't comment on that front.

comment:12 Changed 9 months ago by arma

Hello unhappy anonymous person!

The answer is that nobody has done anything on this ticket yet. We are all still trying to catch up on other things that are more urgent.

We'll let you know once we make real progress here.

In the mean time, you can all read our original guidelines for dir auth choice here:
https://gitweb.torproject.org/torspec.git/tree/attic/authority-policy.txt

comment:13 Changed 9 months ago by cypherpunks

@arma: Thank you! That's a great start to what I'm looking for. And just to clarify: the timeline for removing (or not) urras isn't what worried/worries me. The silence is.

IMO there needs to be:

  • a formal procedure for making the final decision (e.g. "Roger initiates a vote on <mailing list>; dirauths have 3 days to vote yes or no via PGP-signed email; a quorum of 7 votes is sufficient to make a decision; lack of quorum => no change")
  • a formal procedure for removing dirauths (rules will be different to accommodate excluding the instant dirauth from voting)
  • more inclusive and transparent voting process (i.e. figure out some way to take community input)

These are probably better as separate issues. Shall I create tickets for these and leave this ticket for tracking the issue in the title?

-a slightly-more-happy cypherpunk

Last edited 9 months ago by cypherpunks (previous) (diff)

comment:14 Changed 9 months ago by atagar

Certainly makes sense. We can probably leave this as the tracking ticket for now but maybe break it up later. I forwarded this ticket to the dirauths to give a little thought to.

comment:15 Changed 9 months ago by Sebastian

I'm one of the current dirauth ops. Getting anything less than full consensus is not sufficient for the sane operation of the network. Making individual tickets to create formal procedures won't work better than this ticket.

comment:16 Changed 8 months ago by cypherpunks

Thanks for chiming in, Sebastian.

One thing: by consensus, do you mean the actual Tor consensus? Or consensus on voting to add/remove a DirAuth? I assume the latter.

Can you explain why you believe anything less than a full consensus is insufficient? I think I understand, but I want to hear from you.

Are there any other suggestions? Also, what is the progress on finding a replacement for urras?

comment:17 Changed 8 months ago by Sebastian

By consensus I meant consensus amongst dirauth operators, not the actual voting performed by Tor.

dirauth ops have to trust each others judgment, responsiblity in operating the dirauth, performing certain actions at certain times, etc. We already have many technical failure modes and any kind of mistrust amongst the dirauth ops adds a situation where it'll become easier to undermine the security of the network by undermining the security of less than half of the dirauths, which is something we do not want to happen.

The process is that we're looking at candidates, making sure they have the technical capability and experience of running a Tor relay for some time, are able to earn trust from the Tor community at large as well as the dirauth operators community. Then the dirauth ops add them to their configuration and their details are added to the Tor consensus.

comment:18 Changed 8 months ago by cypherpunks

I guess the directory authorities did that faster as expected:

"The following authorities are missing from the consensus: urras"
https://lists.torproject.org/pipermail/tor-consensus-health/2016-July/007220.html

https://lists.torproject.org/pipermail/tor-consensus-health/2016-July/007211.html
https://lists.torproject.org/pipermail/tor-project/2016-July/000491.html

Additional steps:

comment:19 Changed 8 months ago by Sebastian

As of the 1500 UTC consensus a majority of dirauths do indeed no longer include urras in the set.

comment:20 Changed 8 months ago by atagar

DocTor checks for urras have been discontinued. Iirc consensus-health.torproject.org uses Stem's authority list as well so pulling the following should do the trick...

https://gitweb.torproject.org/stem.git/commit/?id=62c6063

I'll give Tom a nudge.

comment:21 Changed 8 months ago by nickm

anybody got a patch for tor? Does anything else get added in, or is only urras dropped?

comment:22 Changed 8 months ago by atagar

We're only dropping urras at this point. If you'd like I can make you a patch but it's such a trivial change thought it would be faster for you to just remove the lines. :)

comment:23 Changed 8 months ago by Sebastian

There is a signed commit in branch urras in my tor repository. It is based on maint-0.2.4, which is the oldest version we're still recommending currently. It does not merge forward cleanly due to the no-v2 flag being removed later. If we want this based on a later version I can also provide that. I did not add anything to the commit message about how this decision was reached, but I can also add it as appropriate.

comment:24 Changed 8 months ago by nickm

  • Keywords TorCoreTeam201607 added
  • Milestone set to Tor: 0.2.9.x-final
  • Status changed from new to merge_ready

comment:25 Changed 8 months ago by nickm

  • Resolution set to implemented
  • Status changed from merge_ready to closed

Merged, added a changes file, and resolved conflicts.

comment:26 Changed 8 months ago by tom

This should now be updated on consensus-health.torproject.org also! No commit needed, just needed to update stem (and test it before doing so.)

Note: See TracTickets for help on using tickets.