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.