draft proposal: download server descriptors on demand

[Mike Perry]

Thus spake Roger Dingledine (arma at mit.edu):

> I think which choice we take depends on the properties of the
> microdescriptor:
>   Option 1 is the best choice if it stays small and changes often (at
>     least daily), since caching it separately from the consensus doesn't
>     save us much bandwidth.
>   Option 2 is the best choice if it stays small and changes seldom.
>   Option 3 is the best choice if it grows large.
> 
> For the current situation -- onion keys that rotate weekly -- I think
> option 2 is the winner. But if we later add something that changes often,
> then option 2 is going to feel like a hassle compared to the simpler
> and just as efficient option 1. And if we ever add a lot more bytes,
> then we're going to want to move to option 3.

It would seem to me that we should just start thinking of the
microdescriptor as the repository for time-insensitive,
longer-duration information about a node. It appears that 141 has
already moved load balancing/bandwidth information to the network
status consensus document. Is there any reason why we couldn't persue
option 2, and if anything comes up that needs to be added that changes
frequently, we can add it to the network status, otherwise we add it
to the microdescriptor?

It also seems like the loss of PFS in the single-roundtrip version of
option 3 is pretty bad given that it would allow malicious or coerced
guard nodes to record circuit creation and then potentially harass
middle nodes for their onion key for full path information at a later
date.. Sad.

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20081113/d344361a/attachment.pgp>