draft proposal: download server descriptors on demand

[Roger Dingledine]

On Mon, Nov 10, 2008 at 07:24:00AM -0500, Roger Dingledine wrote:
> > 2.4 Contact/key information
> > 
> >   A server descriptor lists a server's IP address and TCP ports on which
> >   it accepts onion and directory connections.  Furthermore it contains
> >   the onion key, a short lived RSA key to which clients encrypt CREATE
> >   cells.
> 
> So the plan would be a) teach relays how to answer the request, b) teach
> clients how to ask it so we can test, c) wait until lots of relays support
> it, d) teach clients to ask when the relay is of a sufficient version,
> e) teach clients to stop fetching descriptors the normal way.
> 
> Somewhere in there, we'd also want to make sure that every relay that
> supports this feature mirrors all the descriptors, so they're present
> when requested.
> 
> Ok. So those are my notes on how to proceed in the current direction. In
> my next post I will describe a radical departure that is much easier
> to build.

The new crazy variant is to make clients, and eventually relays, never
see server descriptors at all.

Basically the only thing that clients need that isn't in the consensus now
is the onion key. (They only need identity keys for their entry guards,
and in that case they learn the identity key from the TLS handshake.)

One option is just to stick onion keys in the consensus.
  265090 2008-11-10-10:00:00-consensus
  220223 Okeys
  485313 together
  241365 together.gz
   89874 2008-11-10-10:00:00-consensus.gz
Ok, so that represents a serious increase in the consensus size. Keys
are huge and don't compress very well.

So instead we should do like proposal 141, but fetch the onion key on
demand, rather than the descriptor. The new RELAY_REQUEST_OKEY relay
cell just sends back the onion key. It fits in one cell, so there's no
need to mess with this global padding parameter thing, or compressing
descriptors on the fly, or teaching relays to test if their descriptor
is too big, etc.

Clients never learn exact exit policies now. That means we need to
make exit policies snap-to-fit better into the summaries we put in the
consensus document. But that's true with the old approach to proposal
141 too. The only difference is that now we just try the BEGIN request,
and get end-reason-exit-policy if we guessed wrong and then try elsewhere.

We actually want RELAY_REQUEST_OKEY to be more general, in case there
are other items we want to communicate that we only summarize in the
consensus. RELAY_REQUEST_DETAILS, maybe.

How do the mirrors learn the onion keys? Authorities now produce both a
"mirror consensus" and a "client consensus". They differ in that the
mirror consensus includes the SD hash, descriptor timestamp, and the
onion key; and the client consensus has the OKey hash.

(I worry about consensus synchronization questions. One easy way to
generate them safely is for the authorities to only run their consensus
algorithm on the mirror consensus, generate signatures on that, and then
have a deterministic transform from mirror consensus to client consensus,
and then they generate signatures on that too. Then they ship the blob
with both types of signatures, and mirrors can serve whichever they like.)

With these changes, the client-consensus takes a bit less space than the
current consensus (we basically replace the SD hash and timestamp with
the OKey hash). Even better, consensus diffs (proposal 140) become much
much smaller, since we remove the primary sources of change between one
consensus and the next.

In this model, the authorities still serve the real server descriptors,
so people with esoteric interests (like for torstatus) can fetch them.

Downsides for my crazy idea?

Well, first, it makes it even more starkly clear how much clients trust
the threshold of directory authorities. I would argue that the actual
control clients have over their security doesn't actually change,
though. Also note that since the real server descriptors still exist,
we don't preclude other more decentralized directory mechanisms in
the future or alongside this one. For example, clients are welcome to
continue fetching and caching server descriptors from their bridges,
so they can know bandwidth estimates and other load balancing info.

Another downside is that we have to restrict exit policies pretty
thoroughly. It looks like we were already heading in that direction for
the original proposal 141 too though.

Any other downsides? :)

Now, time to consider some optimizations:

Optimization one: I could be convinced that with consensus diffs,
putting the onion key in the consensus wouldn't be so bad. Or we can put
OKey hashes in the consensus, and then let clients fetch and cache the
onion keys they're missing. They don't change very often at all. Either
way, now we wouldn't have to introduce any new relay cells, and no new
round-trips during circuit generation, and relays don't need a global
view of anything unless they want one. Sure is tempting.

Optimization two is that we could cut out the separate round-trip for
the RELAY_REQUEST_DETAILS relay cell if we wrap it into the CREATE cell.
That is, we could bump the circuit protocol version, and cram more
stuff into the CREATE cell like we've been meaning to, and one of the
new items would be the fingerprint for the intended next hop. Then
the relay can send back a CREATED followed directly by a (series of)
RELAY_HERE'S_YOUR_DETAILS relay cell(s). This step shouldn't be taken
lightly though, a) because it requires bumping the circuit protocol
version (an all-syrup super squishy? such a thing has never been done!),
b) because Ian showed up our create cells are darn fragile already,
so let's be careful putting anything else in them, and c) because the
fingerprint of the next hop is only encrypted to the onion key, and thus
isn't covered by the PFS you'd get if you wait for the CREATED cell first.

--Roger