Proposal: Download consensus documents only when it will be trusted

[Nick Mathewson]

On Sun, Apr 13, 2008 at 05:19:15PM +0200, Peter Palfrader wrote:
> This came up in the More robust consensus voting with diverse authority
> sets thread but is a different issue.
> 
> There are several open issues throughout the proposal and they are
> marked with XXX in the text.
> 
> 
> Filename: 134-robust-voting.txt
> Title: Download consensus documents only when it will be trusted
> Author: Peter Palfrader
> Created: 2008-04-13
> Status: Draft
> 
> Overview:
> 
>   Servers only provide consensus documents to clients when it is known that
>   the client will trust it.

Good idea.
 
  [...]
>   The directory server then only sends back the consensus when more than
>   half of the authorities listed in the request have signed the
>   consensus.  If it is known that the consensus will not be trusted
>   a reasonable error code is sent back to the client.
>   [XXX: What is a reasonable error code?
>         "404 no pon^Wconsensus for you"?]

The client asked for an object we don't have; sounds like a 404 to me.

> 
>   This proposal does not require directory caches to keep more than one
>   consensus document.  This proposal also does not require authorities
>   to verify the signature on the consensus document of authorities they
>   do not recognize.
> 
>   [XXX: Do caches keep signatures from authorities they do not recognize
>         on the consensus document they download currently?  If not, they
>         should.]

They do.

>   [XXX: Is using the existence of a directory-signature block at the end
>         of the consensus sufficient to tell if an authority has signed
>         the consensus?  Can anybody just post signatures and we will
>         distribute them, or will an authority that appends them to the
>         consensus verify the signature, and that this signature's
>         creator is listed in the consensus's dir-source?]

We should look at this.  Right now, we should not accept any signature
from an authority not listed in the consensus as having contributed to
the consensus.  (That is, if there isn't a dir-source line for a given
identity key, we shouldn't accept a signature corresponding to it.)

>   The new URL scheme to download a consensus is
>   /tor/status-vote/current/consensus/<F> where F is a list of
>   fingerprints, sorted in ascending order, and concatenated using a +
>   sign.
> 
>   Fingerprints are uppercase hexadecimal encodings of the authority
>   identity key's digest.  Servers should also accept requests that
>   use lower case or mixed case hexadecimal encodings.
>
> 
>   [XXX: Can we get away with a shortened hex digest?  40 characters per
>         authority brings us up to 600 bytes just for fingerprint part of
>         the GET URL, and some proxies might have issues with URLs that
>         get much longer than that.  What's the worst that can happen
>         when we only use the significant 2 or so bytes (4 hex chars)
>         for this purpose?]

The worst is that the client gets back a consensus it didn't want if
some new authority winds up having a key that matches the key the
client wants in the first N byets.  That doesn't seem disasterous.

>   A .z URL for compressed versions of the consensus will be provided
>   similarly to existing resources and is the URL that usually should
>   be used by clients.
> 
> Migration:
> 
>   The old location of the consensus should continue to work
>   indefinitely.  Not only is it used by old clients, but it is a useful
>   resource for automated tools that do not particularly care which
>   authorities have signed the consensus.
> 
>   Authorities that are known to the client a priori by being shipped
>   with the Tor code are assumed to handle this format.
>   [XXX: or we add a new flag, "v3c" or whatever to the dirserver
>         line.  It depends on how fast we can upgrade the
>         authorities before we add this to client code.]

I don't want to add more flags for this; assuming all the authorities
have upgraded like this is probably OK.

>   When downloading a consensus document from caches clients only pick
>   caches that are known to support this new format.
>   [XXX OR: When downloading a consensus document from caches that
>            do not support this new format they fall back to the old
>            download location].

Falling back to the old location seems smart, or else new clients will
totally stop using old directory servers for consensuses.
 
>   Caches support the new format starting with Tor version [XXX].
> 
> Anonymity Implications:
> 
>   By supplying the list of authorities a client trusts to the directory
>   server we leak information (like likely version of Tor client) to the
>   directory server.  In the current system we also leak that we are
>   very old - by re-downloading the consensus over and over again, but
>   only when we are so old that we no longer can trust the consensus.

Hm.  I don't think that the old approach leaks the exact version quite
so immediately as the new one does, but I agree that the information
extractable is about the same.

> Footnotes:
>  1. For the purpose of this proposal a client can be any Tor instance
>     that downloads a consensus document.  This includes relays,
>     directory caches as well as end users.