draft proposal: download server descriptors on demand

[Christian Fromme]

Hi,

thanks for clearing things up!

On 11.11. 23:57, Roger Dingledine wrote:

> 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.
> 
> Does that mean we should go with option 2, and keep this discussion in
> mind next time we want to add more items to the consensus?

Maybe it really does. It's probably the most practical approach we could
choose for now. Does anybody else have some points here? If nothing
critical comes up, I'd opt for it.

> While I'm at it, what's a good way to version the microdescriptor? We
> could just stick a version byte at the front, but what does a client do
> if it encounters a version it doesn't recognize? About the only plan
> I can come up with is to put a version byte in front, and if we want
> to add things just add them, and clients ignore stuff beyond what they
> know to look for in a given version. If we need to change the version,
> we teach clients about both while still using the old one, and once
> all the clients have upgraded we switch to the new one (at which point
> clients can then forget how to understand the old one). Slow process.

Why do we need a slow upgrade process when microdescriptors are, as you
describe, backward compatible? I am missing something I guess. ;) 
Apart from that I think a byte in front for the versioning is fine.

> Another point to ponder: nickm was talking about having relays generate
> their own microdescriptors and sign them, and then maybe saving space
> by not including the signature when clients fetch it. I think the
> microdescriptor should be a straight transform from the 'real' descriptor,
> and so it doesn't need any signature or timestamp. Relays don't even
> need to know that they exist, except as opaque blobs that they mirror.

Is there a good reason for signing the descriptors? From a security
perspective, since the current descriptors aren't signed, why signing
the new microdescriptors? Again, I might be missing something here. In
option #2, if this is the one we'll implement, relays don't mirror the
descriptors anyway, they come straight from the trusted dirservers.


Best,
Christian