[tor-dev] Proposal 227: Include package fingerprints in consensus documents

[Georg Koppen]

Hi,

Nick Mathewson:
> Here's a new proposal for a thing that Mike wants for TBB.  Please review!

[snip]

> 2. Proposal
> 
>    We introduce a new line for inclusion in votes and consensuses.
>    Its format is:
> 
>      "package" SP PACKAGENAME SP VERSION SP URL SP DIGESTS NL
> 
>       PACKAGENAME = NONSPACE
>       VERSION = NONSPACE
>       URL = NONSPACE
>       DIGESTS = DIGEST | DIGESTS SP DIGEST
>       DIGEST = DIGESTTYPE "=" BASE64

What about "DIGESTTYPE"? While everything else seems to be properly
defined I am not sure what this one is referring to.

>       NONSPACE = one or more non-space printing characters
> 
>       BASE64 = one or more base-64 characters, with trailing =s

"="s or "equal signs" instead

[snip]

>    Votes and consensuses may include any number of "package" lines,
>    but no vote or consensus may include more than one "package" line
>    with the same PACKAGENAME and VERSION values.  All "package"
>    lines must be sorted by PACKAGENAME, and then by VERSION, in
>    lexical (strcmp) order.
> 
>    If the consensus-method is at least (TBD), then when computing
>    the consensus, package lines for a given PACKAGENAME/VERSION pair

"package"

>    should be included if at least three authorities list such a
>    package in their votes.  (Call these lines the "input" lines for
>    PACKAGENAME.)  That consensus should contain every "package" line
>    that is listed verbatim by more than half of the authorities
>    listing a line for the PACKAGENAME/VERSION pair, and no
>    others.

Hmm... What happens in cases like the following:

4 authorities include a PACKAGENAME/VERSION pair with URL1 and DIGEST1
and 4 other authorities include the same PACKAGENAME/VERSION pair with
URL2 and DIGEST2 and, say, 1 authority includes no such
PACKAGENAME/VERSION pair at all? Which line gets included given that
only one of them can make it into the consensus?

>    These lines appear immediately following the client-versions and
>    server-versions lines.
> 
> 3. Recommended usage
> 
>    Programs that want to use this facility should pick their
>    PACKAGENAME values, and arrange to have their versions listed in
>    the consensus by at least three friendly authority operators.
> 
>    Programs may want to have multiple PACKAGENAME values in order to

"MAY"

[snip]

>    To avoid synchronization problems, programs that use the DIGEST
>    field to store a digest of the contents of the URL SHOULD NOT use

What do you mean with "store" in this context? TBB is supposed to use
the DIGEST field but I don't think to store a digest, no?

> 3.1. Intended usage by the Tor Browser Bundle

Just a thought: I am wondering if that section really fits into this
proposal. Given the complexities of the update process and necessary
defenses against different attacks/adversaries the update process might
merit an own proposal, I think.

>    Tor Browser Bundle packages will be listed with package names
>    'tbb-stable, 'tbb-beta', and 'tbb-alpha'. We will list a line for

"'tbb-stable'" and/or maybe replace "'" with the quotation mark used in
the previous sections of this proposal for consistency.

>    the latest version of each release series.
> 
>    When the updater downloads a new update, it always downloads the
>    latest version of the Tor Browser Bundle. Because of this, and

Hopefully, yes :) But it is not guaranteed if there is a (successful)
replay attack.

>    because we will only use these lines to authenticate updates, we
>    should not need to list more than one version per series in the
>    consensus.
> 
>    After completing a package download and verifying the download
>    signatures (which are handled independently from the Tor
>    Consensus), it will consult the appropriate current consensus
>    document through the control port.
> 
>    If the current consensus timestamp is not yet more recent than
>    the proposed update timestamp, the updater will delay installing
>    the package until a consensus timestamp that is more recent than
>    the update timestamp has been obtained by the Tor client.
> 
>    If the consensus document has a package line for the current
>    release series with a matching version, it will then download the

I was stumbling over "it". It might be better to use "the updater" instead.

>    file at the specified URL, and then compute its hash to make sure
>    it matches the value in the consensus.
> 
>    If the hash matches, the Tor Browser will download the file and
>    parse its contents, which will be a JSON file which lists

"will download a JSON file and parse its content, which lists"

>    information needed to verify the hashes of the downloaded update
>    file.
> 
>    If the hash does not match, the Tor Browser Bundle should display
>    an error to the user and not install the package.
> 
>    If there are no package lines in the consensus for the expected
>    version, the updater will delay installing the update (but the
>    bundle should still inform the user they are out of date and may
>    update manually).

How can the bundle be sure that it is out of date? Maybe there is an
important reason that the consensus does not contain the expected
package line (e.g. the TorBrowser only got tricked into believing a new
update exists). I agree that there should be a warning shown to the
user, though.

Georg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 862 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140221/86b459e4/attachment.sig>