Re: [tor-dev] Review of Proposal 147: Eliminate the need for v2 directories in generating v3 directories

[Karsten Loesing <karsten@xxxxxxxxxxxxxx>]

On 1/6/14 7:55 PM, Nick Mathewson wrote:
> On Tue, Dec 24, 2013 at 3:55 AM, Karsten Loesing <karsten@xxxxxxxxxxxxxx> wrote:
>> On 12/17/13 10:31 PM, Nick Mathewson wrote:
>>> 147  Eliminate the need for v2 directories in generating v3 directories
>>>
>>>      This proposal explains a way that we can phase out the
>>>      vestigial use of v2 directory documents in keeping authorities
>>>      well-informed enough to generating the v3 consensus.  It's
>>>      still correct; somebody should implement it before the v2
>>>      directory code rots any further. (5/2011)
>>
>> This proposal looks plausible to me.  Some minor remarks:
>>
>> - The proposal suggests that authorities send an opinion document to the
>> other authorities "at the regular vote upload URL".  URLs are cheap, why
>> not use a different URL to keep things separated, e.g., /tor/post/opinion ?
> 
> sure.

Okay, starting a patch with proposal 147 tweaks and changing this URL as
suggested.

>> - Should dir-spec.txt suggest a timing for pushing-and-pulling opinion
>> documents?  Authorities could send their opinions at :45:00 and fetch
>> missing opinions at :47:30.  This could be defined by a new
>> OpinionSeconds part contained in "voting-delay" lines.  This would be a
>> SHOULD requirement, not a MUST requirement.
> 
> This is plausible.

Added to the proposal.

>> - The proposal doesn't say what lines must be contained in opinion
>> documents.  It seems that an authority that parses an opinion document
>> is only interested in a) relay fingerprint, b) descriptor publication
>> time, and c) descriptor digest; unless there's more information that
>> helps authorities decide whether "they might accept" a descriptor.  If
>> not, opinion documents only need to contain a small subset of headers
>> and all the "r" lines that would be contained in a later vote.
> 
> This also seems okay.  It would however mean that we can't use the
> same parsing logic as we use for regular votes.

True.  Added as two comments to the proposal.

>> - The proposal doesn't explicitly say this, so just to be sure: when an
>> authority finds that it's missing a router descriptor that it then
>> downloads, it also downloads the corresponding extra-info descriptor
>> afterwards, right?
> 
> I suppose it should.

Added.

>> - Another thing that is left implicit in the proposal: the opinion
>> document will always contain the valid-after time of the *next*
>> consensus.  Well, the URL /tor/status-vote/next/opinion implies that,
>> but maybe we should explicitly mention this in dir-spec.txt.
> 
> Hm. maybe valid-after and valid-until should just get ignored on
> opinions. Or omitted.

Added as comments.

> Also, ISTR that Roger told me that this whole proposal didn't actually
> seem to be necessary in practice. I wish I could remember the
> rationale, though.

I talked to Roger on IRC, and here's why this proposal may indeed be
overkill:

As of January 2013, there is only a single version 3 directory authority
left that serves version 2 statuses: dizum.  moria1 and tor26 have been
rejecting version 2 requests for a long time, and it's mostly an
oversight that dizum still serves them.  The other six authorities have
never generated version 2 statuses for others to be used as pre-voting
opinions.  So, it's basically not true that version 2 statuses are
required for the version 3 protocol to work properly.

Here's a possible way to move this forward.

- Please review and merge my prop147tweaks branch that contains tweaks
from our discussion above, regardless of whether this proposal will be
implemented or not.

- I'm going to run a quick analysis of archived vote documents to see
how much authorities would have benefited from the others' votes before
generating their own votes.

- I'm going to ask Alex to disable version 2 statuses on dizum using
DisableV2DirectoryInfo_ 1 to see what that does to the network.  We
should probably finish the 2048 bits RSA keys upgrade first before
changing yet another variable.

- If there's no convincing argument to implement opinion documents, we
close this proposal as rejected.

What do you think?

All the best,
Karsten

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev