Thus spake Roger Dingledine (arma@xxxxxxx): > 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
Attachment:
pgpTQ17B9kNvl.pgp
Description: PGP signature