Plan for proposal 104 (was: New system for modifying Tor protocol)

[Nick Mathewson]

On Mon, Mar 12, 2007 at 12:37:06AM -0400, Roger Dingledine wrote:
 [...]
> > The remaining issue in my mind is: if later we decide that we need to
> > keep "extra info" documents verifiably reconciled among authorities,
> > will we then wish that we had done more now to make it possible to do
> > so in the future.  In particular, upgrading authorities is easy, but
> > upgrading all the servers on the network isn't.  What server-side work
> > would we need to do to make extra-info documents reconcilable, and how
> > much of it (if any) needs to happen now?
> 
> Notice that whenever we create a short descriptor we'll also be creating
> a long descriptor.

(Note that I've been using "long descriptor" to mean "a thing just
like the short descriptor, but with extra info," and I've been using
"extra info doc" to mean "a thing containing _only_ the extra info."
I'm not sure that's 100% clear, but I wanted to make sure we were
using the terms consistently.)

> (Otherwise there's important info that the current
> short descriptor has but the current long descriptor doesn't have, and
> we'll be creating bad incentives for our tool writers again.)

Well, the 'bad incentive' (as you've clarified elsewhere) would be to
download _both_, but that's not such a problem if there isn't much
redundant info, and if the number of tool instances that want the
extra info is relatively small compared to the number of Tor
instances.

But to my mind there's another bad incentive if the long descriptors
_do_ include all of the info of the short descriptors: if tools just
download all of the long-descriptor info as a big blob, then they have
only the directories' word that the information is really the same as
in the short descriptors, unless they also download the short
descriptors and that the information matches.  But if they're going to
do that, they can just check whether the hashes match.

Hm.  If we're going to ship this and expect people to use it, we
should actually write the code to do the downloading and check whether
the extrainfo/longdesc hashes seem right.

 [...]
> To add suspenders as well as belt, we could include a hash of the long
> descriptor in the short descriptor -- basically "solution 3" in the
> proposal. The caveat listed in the proposal isn't necessarily true if
> we do solutions 3 and 4 together: you don't need to know which longdescs
> to fetch if you just fetch all of them.

This is a pretty good point; I think this is the way we should go.
I'm thinking we need another draft on the proposal before we can call
it done, but we're making good progress.

yrs,
-- 
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070315/8552e172/attachment.pgp>