1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
|
Filename: 239-consensus-hash-chaining.txt
Title: Consensus Hash Chaining
Author: Nick Mathewson, Andrea Shepard
Created: 06-Jan-2015
Status: Open
1. Introduction and overview
To avoid some categories of attacks against directory authorities
and their keys, it would be handy to have an explicit hash chain in
consensuses.
2. Directory authority operation
We add the following field to votes and consensuses:
previous-consensus ISOTIME [SP HashName "=" Base16]* NL
where HashName is any keyword.
This field may occur any number of times.
The date in a previous-consensus line in a vote is the valid-after
date of the consensus the line refers to. The hash should be
computed over the signed portion of the consensus document. A
directory authority should include a previous-consensus line for a
consensus using all hashes it supports for all consensuses it knows
which are still valid, together with the two most recently expired
ones.
When this proposal is implemented, a new consensus method should be
allocated for adding previous-consensus lines to the consensus.
A previous-consensus line is included in the consensus if and only
if a line with that date was listed by more than half of the
authorities whose votes are under consideration. A hash is included
in that line if the hash was listed by more than half of the
authorities whose votes are under consideration. Hashes are sorted
lexically with a line by hashname; dates are sorted in temporal
order.
If, when computing a consensus, the authorities find that any
previous-consensus line is *incompatible* with another, they must
issue a loud warning. Two lines are incompatible if they have the
same ISOTIME, but different values for the the same HashName.
The hash "sha256" is mandatory.
3. Client and cache operation
All parties receiving consensus documents should validate
previous-consensus lines, and complain loudly if a hash fails to
match.
When a party receives a consensus document, it SHOULD check all
previous-consensus lines against any previous consensuses it has
retained, and if a hash fails to match it SHOULD warn loudly in the
log mentioning the specific hashes and valid-after times in
question, and store both the new consensus containing the
mismatching hashes and the old consensus being checked for later
analysis. An option SHOULD be provided to disable operation as a
client or as a hidden service if this occurs.
All relying parties SHOULD by default retain all valid consensuses
they download plus two; but see "Security considerations" below.
If a hash is not mismatched, the relying party may nonetheless be
unable to validate the chain: either because there is a gap in the
chain itself, or because the relying party does not have any of the
consensuses that the latest consensus mentions. If this happens,
the relying party should log a warning stating the specific cause,
the hashes and valid-after time of both the consensus containing the
unverifiable previous-consensus line and the hashes and valid-after
time of the line for each such line, and retain a copy of the
consensus document in question. A relying party MAY provide an
option to disable operation as a client or hidden service in this
event, but due to the risk that breaks in the chain may occur
accidentally, such an option SHOULD be disabled by default if
provided.
If a relying party starts up and finds only very old consensuses
such that no previous-consensus lines can be verified, it should log
a notice of the gap along the lines of "consensus (date, hash) is
quite new. Can't chain back to old consensus (date, hash)". If it
has no old consensuses at all, it should log an info-level message
of the form "we got consensus (date, hash). We haven't got any
older consensuses, so we won't do any hash chain verification"
4. Security Considerations:
* Retaining consensus documents on clients might leak information
about when the client was active if a disk is later stolen or the
client compromised. This should be documented somewhere and an
option to disable (but thereby also disable verifying
previous-consensus hashes) should be provided.
* Clients MAY offer the option to retain previous consensuses in
memory only to allow for validation without the potential disk
leak.
|
