Automated directories / key rotation / threshold dirservers

[Roger Dingledine]

On Fri, Sep 19, 2003 at 09:51:21AM -0700, Aaron Turner wrote:
> You didn't mention, but I assume that there will be a central CA which
> signs these permanent keys?  It also allows you to prevent two routers
> from choosing the same nickname (you won't sign a key if the nickname
> is already taken).

Not currently. You generate an identity key on your own, and send a
nickname and hash of that key out-of-band to each dirserver operator. If
the operator likes you, then he adds that line to his approved-routers
file and hups his router. If the dirserver includes you in his directory,
then users will learn about you; otherwise nobody will know about you.

Currently we assume that all dirservers have the same policy for deciding
if they like you; reconciling differences is a hard problem that needs
more research -- and experience -- to figure out what we really want.

> > In any case, now the dirserver routers.or file just needs to have
> > the nickname and identity key of "approved" routers. (Approved means
> > I've looked at them, to reduce Sybil attacks.)
> 
> I see no reason why this can't be automated just prior to signing as I
> suggested above.  Depending on how fancy you want to get, do some
> challenge-response thing which requires human interaction.  There are a
> variety of webbased solutions for this: anti-OCR characters which
> require the human to type in would be my first suggestion, probably
> along with requiring a valid email address and limits on the number of
> OR routers allowed to be registered by a given IP or IP block.

Currently we want stronger control over who can join -- I only want to
allow people that I know personally. It's not clear yet how vulnerable
the network is to bad guys; certainly it is far more vulnerable than
mixes.

But it's true, we could automate the process down the road, so you go
to a webpage cgi and after passing its tests three, you get approved.

> Maybe someting like dynamic dns?  DDNS works just like regular DNS,
> except that DHCP clients tell the DNS server "hey I'm aarons-laptop and
> I just changed my IP to x.x.x.x"

Yes, that's clearly the sort of protocol we're looking for here. But
DDNS doesn't do signing, key management, etc (does it?), which is the
bulk of the tricky part here.

> The idea here being is that each OR needs only to tell one dirserver
> which then syncs with other dirservers on a regular basis.  The
> advantage of this that the dirservers are self healing when corruption
> occurs.  Dirservers delete corrupted records and re-learn them from
> other dirservers or when a router notices he's not listed and re-teaches
> the dirserver.

Right. I think the dirservers should periodically fetch directories
from the other dirservers, and learn about new descriptors from the
other directories.

> > Which brings us to the question of directory synchronization. A single
> > directory is a clear security and robustness bottleneck, yet there
> > are security and robustness problems if clients get different network
> > views from different dirservers (attacks where the adversary can guess
> > the initiator based on what directories have been given out; and simple
> > robustness issues where a given router doesn't know that another router
> > is up). For simplicity, we assume that all the participants will agree
> > on who the dirservers are. I guess that means for now that we force an
> > upgrade when the set of dirservers changes; later we can investigate
> > allowing partially different dirserver sets.
> 
> Seems to me you could just list the valid dirservers in the dirserver
> itself.  Basically, as long as you know one valid dirserver, you can
> learn about them all.

Let me rephrase my threat model from above. We assume that Roger
decides who the dirservers are, and gets that information securely to
all participants. I'd like it to be that a few dirservers (less than
some threshold) can't do much damage (eg by telling everybody about a
bunch of new dirservers and then suddenly shifting everybody away from
the chosen dirservers without noticing).

The nice thing about thresholds ("k out of n trusted dirservers signed
this, so I'll believe it") is that we can avoid flag days: a few
dirservers can expire or join the network before a given user is forced
to upgrade.

> Actually, have you considered using DNS w/ DNS-Sec and TXT records?  Yes
> BIND is complicated and big, but it basically does everything you need.
> Dirservers are nothing but NS records, OR's are A records, and the OR
> record would map onto a TXT record.  Getting a complete list of all the
> OR's is a zone transfer. DNS already does everything you need (event
> based propagation, expiration, retries, redundancy, authentication, etc).

It's a neat analogy, but I'm not convinced bind will do what we
want. First off, dnssec is even trickier than dns. Secondly, we're aiming
for an auditable program at the source-code level, so "just adding bind"
kills that outright. (One could argue that "just adding openssl" has
already killed that. One may well be right.) Thirdly, we want to be easily
and conveniently deployable on a variety of platforms, especially Win32.
Fourthly, we want to be aware of the protocol and how we're doing it,
so we can consider anonymity issues which bind doesn't have to care about.

I do find myself answering the question "why not just use this bloated
thing over here, it does what you want, among many other things" often
these days. (The last one was "why not use twisted".) It's a shame that
useful libraries tend to grow into incomprehensible heaps of code. Maybe
they're forced into it by the specs, or by the need for portability.
I guess we'll see how long Tor lasts before succumbing. :)

Thanks,
--Roger