[tor-dev] Proposal xxx: Consensus Hash Chaining

[Sebastian G. <bastik.tor>]

06.01.2015, 18:51 Andrea Shepard:
> All relying parties SHOULD by default retain all valid consensuses they
> download plus two; [...]

Unfortunately I did not consider this in my previous mail, but this does
not account for the possibility that the valid-until ever increases.

Depending on valid-until there might be a huge pile of valid consensuses
that will take some space.

Depending on what it buys a relying party some more or less future-proof
defaults like let's say four consensuses whose valid-until is not
expired and two whose valid-until expired most recently.

Long running parties will have checked the previous-consensus lines for
consensuses that are expired for longer than they are kept.

Maybe a torrc option would be a good idea for clients or bridges on
hardware with less storage space. Maybe even relays and exits don't have
storage space, when they are run something like RAMDISK.

I might lack to understand the importance of keeping all consensuses
that are still valid, but if it's just checking the hash by having them
chained why couldn't Tor compute the hash(es), store it/them with the
consensuses valid-after time and valid-until time in a separate file and
then check that file if the latest consensus contains valid hashes in
previous-consensus lines it knows about to be valid or recently expired?

It might not necessary to specify in the proposal since it says:

> [...] if a hash fails to match it SHOULD warn loudly in the log
> mentioning the specific hashes and valid-after times in question [...]

but, what if a previous-consensus line is included with SHA256 and
SHA512 and one of them mismatches? Are relying parties expected to throw
a warning if ANY of the hashes mismatch or just if they fail to validate
one? I guess it shouldn't happen at all, but for security reasons it
seems to be better to make relying parties warn if anything goes wrong.

Best Regards,
Sebastian G.