Simplifying directory authority administration

[Nick Mathewson]

[More discussion on proposal 113.]

On Thu, Apr 26, 2007 at 03:16:33AM -0400, Roger Dingledine wrote:
 [...]
> > +  Worse, name binding is a common path, but it's a pain in the neck: nobody
> > +  has done it for a couple of months.
> 
> A related problem is that people register nicknames and then vanish,
> and a year or two later somebody picks the same nickname and is locked
> out of the network -- in a way that isn't really intuitive to the poor
> server operator.

Agreed, but separate.  Let's get them a better error, and let's
give names a safe way to time-out when unused.

(To get unused names to disappear safely, you'd probably want some
means to tell users "It's not safe to use name X any more.")

> A deeper problem is really that naming isn't very useful anymore. Once
> upon a time we imagined that people would refer to servers by nickname,
> and an unamed server was not recommended for use. Requiring an email was
> in large part a Sybil deterrent. Then we scaled past the point where
> that was practical -- so we started letting unnamed servers be used in
> ordinary situations, and even let multiple servers with the same nickname
> join the network. We migrated to referring to servers by identity key,
> because that's the unique identifier now.
> 
> So part of the reason that name binding isn't actively done anymore is
> that it doesn't (seem to) matter enough.

Right.  It matters _a little_, though.  I still believe that people
are referring to servers by name, for example; when I see
foo.server.exit addresses and torrc configurations, people seem to use
nicknames, even when they know they shouldn't.  (The
prevent-sybil-with-naming goal and the don't-use-unnamed-servers goal
do indeed seem defunct.)

> Indeed, the main reason for answering name registration mail is not to
> get the name on record -- it's to make the server operator feel welcome,
> and to help catch misconfigurations and confusions early.
>
> While we're listing problems with the Named flag, its utility is also
> limited because we're missing an Unnamed flag: if only one directory
> authority has a binding for a given nickname, and the named server hasn't
> published a descriptor recently, then some other server can arrive in
> the meantime with the same nickname and it will be listed by the other
> n-1 dir authorities. (But the naive implementation of this lets a single
> dir authority cut out any server(s) it chooses from the network; looks
> like more research remains here.)

Agreed, and also separable.  I^WWe^WSomebody should think about this
and try to write this up as a separate proposal.  Proposal 101 gives
us a nice time to do a lot of directory-related changes; if this is
something we should do, we should do it soon.

> 
> We could also imagine a client-side Naming strategy, where clients bind
> keys to nicknames the first time they reference them, and then store
> the binding locally.

I dislike this for two reasons:
  - It keeps on the client side a record of every server the client
    has ever referred to by name.  That sounds like a security problem.
  - It keeps users from communicating usefully.  There's not much
    point in saying "I know the guy who runs Dizum; he can be trusted"
    if there's no way to tell that your friend will get the right Dizum.

> 
> But in the interest of not expanding this proposal to include all the
> issues with name binding, I'm going to try to focus on the easiest and
> simplest to deploy that will solve a few of the immediate problems.
> 

 [...]

Thanks for the comments on the "possible solutions" areas.  Something
I didn't see, though, was feedback from your standpoint as an
authority operator.  Between the solutions listed, which would you
actually be willing to do the legwork for as the administrator
operator, and which would get unused the way that the current naming
system is getting unused today?

(I'd also like to hear from weasel and the other authority ops about
this.)

yrs,
-- 
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070427/04416d78/attachment.pgp>