diff options
Diffstat (limited to 'dir-spec.txt')
| -rw-r--r-- | dir-spec.txt | 75 |
1 files changed, 57 insertions, 18 deletions
diff --git a/dir-spec.txt b/dir-spec.txt index 873225d..0de986f 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -395,7 +395,7 @@ Table of Contents upload after this time. (0.4.4.1-alpha was the first version to reject votes in this way.) - Note: Refusing late uploaded votes minimises the chance of a consensus + Note: Refusing late uploaded votes minimizes the chance of a consensus split, particular when authorities are under bandwidth pressure. If an authority is struggling to upload its vote, and finally uploads to a fraction of authorities after this period, they will compute a consensus @@ -711,7 +711,6 @@ Table of Contents - Any OOM invocation due to memory pressure - Any ntor onionskins are dropped - TCP port exhaustion - - DNS timeout reached The timestamp is when at least one metrics was detected. It should always be at the hour and thus, as an example, "2020-01-10 13:00:00" is an @@ -1331,6 +1330,8 @@ Table of Contents is first added after the relay has been running for at least 24 hours. + (Introduced in tor-0.4.6.1-alpha) + "hidserv-rend-relayed-cells" SP NUM SP key=val SP key=val ... NL [At most once.] "hidserv-rend-v3-relayed-cells" SP NUM SP key=val SP key=val ... NL @@ -1351,6 +1352,8 @@ Table of Contents integer and included as 'NUM'. Note that the overall reported value can be negative. + (Introduced in tor-0.4.6.1-alpha) + "hidserv-dir-onions-seen" SP NUM SP key=val SP key=val ... NL [At most once.] "hidserv-dir-v3-onions-seen" SP NUM SP key=val SP key=val ... NL @@ -1366,6 +1369,8 @@ Table of Contents of this line. Note that the overall reported value can be negative. + (Introduced in tor-0.4.6.1-alpha) + "transport" transportname address:port [arglist] NL [Any number.] @@ -1429,7 +1434,7 @@ Table of Contents The "{read|write}-overload-count" are the counts of how many times the reported limits of burst/rate were exhausted and thus the maximum - between the read and write count occurances. To make the counter more + between the read and write count occurrences. To make the counter more meaningful and to avoid multiple connections saturating the counter when a relay is overloaded, we only increment it once a minute. @@ -2241,7 +2246,7 @@ Table of Contents [At most once] - See shared-rand-current-value decription above. + See shared-rand-current-value description above. The authority section of a consensus contains groups of the following items, in the order given, with one group for each authority that contributed to @@ -2288,10 +2293,11 @@ Table of Contents signed (that is, not including the signature) by the RSA identity key (see section 1.3.), encoded in base64. - "Publication" is the publication time of its most recent descriptor, - in the form YYYY-MM-DD HH:MM:SS, in UTC. Implementations MAY base - decisions on publication times in the past, but MUST NOT reject - publication times in the future. + "Publication" was once the publication time of the router's most + recent descriptor, in the form YYYY-MM-DD HH:MM:SS, in UTC. Now + it is only used in votes, and may be set to a fixed value in + consensus documents. Implementations SHOULD ignore this value + in non-vote documents. "IP" is its current IP address; ORPort is its current OR port, "DirPort" is its current directory port, or "0" for "none". @@ -2329,8 +2335,13 @@ Table of Contents "Fast" if the router is suitable for high-bandwidth circuits. "Guard" if the router is suitable for use as an entry guard. "HSDir" if the router is considered a v2 hidden service directory. + "MiddleOnly" if the router is considered unsuitable for + usage other than as a middle relay. Clients do not need + to handle this option, since when it is present, the authorities + will automatically vote against flags that would make the router + usable in other positions. (Since 0.4.7.2-alpha.) "NoEdConsensus" if any Ed25519 key in the router's descriptor or - microdesriptor does not reflect authority consensus. + microdescriptor does not reflect authority consensus. "Stable" if the router is suitable for long-lived circuits. "StaleDesc" if the router should upload a new descriptor because the old one is too old. @@ -2342,7 +2353,7 @@ Table of Contents "Valid" if the router has been 'validated'. Clients before 0.2.9.4-alpha would not use routers without this flag by default. Currently, relays without this flag are omitted - fromthe consensus, and current (post-0.2.9.4-alpha) clients + from the consensus, and current (post-0.2.9.4-alpha) clients assume that every listed relay has this flag. "V2Dir" if the router implements the v2 directory protocol or higher. @@ -2638,6 +2649,13 @@ Table of Contents authority believes that it's been up for at least 96 hours (or the current value of MinUptimeHidServDirectoryV2). + "MiddleOnly" -- An authority should vote for this flag if it believes + that a relay is unsuitable for use except as a middle relay. When + voting for this flag, the authority should also vote against "Exit", + "Guard", "HsDir", and "V2Dir". When voting for this flag, if the + authority votes on the "BadExit" flag, the authority should vote in + favor of "BadExit". (This flag was added in 0.4.7.2-alpha.) + "NoEdConsensus" -- authorities should not vote on this flag; it is produced as part of the consensus for consensus method 22 or later. @@ -2935,7 +2953,7 @@ Table of Contents entries. * If consensus-method 26 or later is in use, then we initialize - bandwith weights to 1 in our calculations, to avoid + bandwidth weights to 1 in our calculations, to avoid division-by-zero errors on unusual networks. * If consensus method 27 or later is used, the microdesc consensus @@ -2957,6 +2975,17 @@ Table of Contents "bwweightscale" and "maxunmeasuredbw" parameters correctly when computing votes. + * If consensus method 32 or later is used, authorities handle the + "MiddleOnly" flag specially when computing a consensus. When the + voters agree to include "MiddleOnly" in a routerstatus, they + automatically remove "Exit", "Guard", "V2Dir", and "HSDir". If + the BadExit flag is included in the consensus, they automatically + add it to the routerstatus. + + * If consensus method 33 or later is used, and the consensus + flavor is "microdesc", then the "Publication" field in the "r" + line is set to "2038-01-01 00:00:00". + The signatures at the end of a consensus document are sorted in ascending order by identity digest. @@ -3026,7 +3055,7 @@ Table of Contents "11" -- Don't consider BadExits when calculating bandwidth weights "12" -- Params are only included if enough auths voted for them "13" -- Omit router entries with missing microdescriptors. - "14" -- Adds support for "a" lines in ns consensues and microdescriptors. + "14" -- Adds support for "a" lines in ns consensuses and microdescriptors. "15" -- Adds support for "p6" lines. "16" -- Adds ntor keys to microdescriptors "17" -- Adds "Unmeasured=1" flags to "w" lines @@ -3039,7 +3068,7 @@ Table of Contents "24" -- No longer lists routers that are not Valid in the consensus. "25" -- Vote on recommended-protocols and required-protocols. "26" -- Initialize bandwidth weights to 1 to avoid division-by-zero. - "27" -- Adds support for "a" lines in microdescriptor consensues. + "27" -- Adds support for "a" lines in microdescriptor consensuses. "28" -- Removes "a" lines from microdescriptors. "29" -- Canonicalizes families in microdescriptors. "30" -- Removes padding from ntor-onion-key. @@ -3560,7 +3589,7 @@ Table of Contents they're about to serve match the right hashes (either the hashes from the fetch URL or the hashes from the consensus, respectively). - (NOTE: Due to squid proxy url limitations at most 92 microdescrriptor hashes + (NOTE: Due to squid proxy url limitations at most 92 microdescriptor hashes can be retrieved in a single request.) 4.4. Downloading extra-info documents from directory authorities @@ -4162,10 +4191,20 @@ C. Converting a curve25519 public key to an ed25519 public key [Recomputing the sign bit from the private key every time sounds rather strange and inefficient to me… —isis] - Alternatively, without access to the corresponding ed25519 private - key, one may use the Montgomery u-coordinate to recover the - Montgomery v-coordinate by computing the right-hand side of the - Montgomery curve equation: + Note that in addition to its coordinates, an expanded Ed25519 private key + also has a 32-byte random value, "prefix", used to compute internal `r` + values in the signature. For security, this prefix value should be + derived deterministically from the curve25519 key. The Tor + implementation derives it as SHA512(private_key | STR)[0..32], where + STR is the nul-terminated string: + + "Derive high part of ed25519 key from curve25519 key\0" + + + On the client side, where there is no access to the curve25519 private + keys, one may use the curve25519 public key's Montgomery u-coordinate to + recover the Montgomery v-coordinate by computing the right-hand side of + the Montgomery curve equation: bv^2 = u(u^2 + au +1) |