diff options
| -rw-r--r-- | dir-spec.txt | 61 | ||||
| -rw-r--r-- | proposals/326-tor-relay-well-known-uri-rfc8615.md | 7 | ||||
| -rw-r--r-- | rend-spec-v3.txt | 2 |
3 files changed, 65 insertions, 5 deletions
diff --git a/dir-spec.txt b/dir-spec.txt index ed5d7b2..6f8efff 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -3448,6 +3448,10 @@ FPRLIST is +-separated list of recognized authority identity fingerprints as in appendix B. +4.6 Retrying failed downloads + + See section 5.5 below; it applies to caches as well as clients. + 5. Client operation Every Tor that is not a directory server (that is, those that do @@ -3658,6 +3662,63 @@ (This section is removed; authorities no longer assign the 'Named' flag.) +5.5. Retrying failed downloads + + This section applies to caches as well as to clients. + + When a client fails to download a resource (a consensus, a router + descriptor, a microdescriptor, etc) it waits for a certain amount of + time before retrying the download. To determine the amount of time + to wait, clients use a randomized exponential backoff algorithm. + (Specifically, they use a variation of the "decorrelated jitter" + algorithm from + https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/ .) + + The specific formula used to compute the 'i+1'th delay is: + + Delay_{i+1} = MIN(cap, random_between(lower_bound, upper_bound))) + where upper_bound = MAX(lower_bound+1, Delay_i * 3) + lower_bound = MAX(1, base_delay). + + The value of 'cap' is set to INT_MAX; the value of 'base_delay' + depends on what is being downloaded, whether the client is fully + bootstrapped, how the client is configured, and where it is + downloading from. Current base_delay values are: + + Consensus objects, as a non-bridge cache: + 0 (TestingServerConsensusDownloadInitialDelay) + + Consensus objects, as a client or bridge that has bootstrapped: + 0 (TestingClientConsensusDownloadInitialDelay) + + Consensus objects, as a client or bridge that is bootstrapping, + when connecting to an authority because no "fallback" caches are + known: + 0 (ClientBootstrapConsensusAuthorityOnlyDownloadInitialDelay) + + Consensus objects, as a client or bridge that is bootstrapping, + when "fallback" caches are known but connecting to an authority + anyway: + 6 (ClientBootstrapConsensusAuthorityDownloadInitialDelay) + + Consensus objects, as a client or bridge that is bootstrapping, + when downloading from a "fallback" cache. + 0 (ClientBootstrapConsensusFallbackDownloadInitialDelay) + + Bridge descriptors, as a bridge-using client when at least one bridge + is usable: + 10800 (TestingBridgeDownloadInitialDelay) + + Bridge descriptors, otherwise: + 0 (TestingBridgeBootstrapDownloadInitialDelay) + + Other objects, as cache or authority: + 0 (TestingServerDownloadInitialDelay) + + Other objects, as client: + 0 (TestingClientDownloadInitialDelay) + + 6. Standards compliance All clients and servers MUST support HTTP 1.0. Clients and servers MAY diff --git a/proposals/326-tor-relay-well-known-uri-rfc8615.md b/proposals/326-tor-relay-well-known-uri-rfc8615.md index cd7f074..a741e1c 100644 --- a/proposals/326-tor-relay-well-known-uri-rfc8615.md +++ b/proposals/326-tor-relay-well-known-uri-rfc8615.md @@ -10,8 +10,7 @@ Status: Open This is a specification for a well-known [registry](https://www.iana.org/assignments/well-known-uris/) entry according to [RFC8615](https://tools.ietf.org/html/rfc8615). -This resource identifier is used for the the verification of [Tor](https://www.torproject.org/) relay contact information -(more specifically the [operatorurl](https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/#operatorurl)). +This resource identifier can be used for serving and finding proofs related to [Tor](https://www.torproject.org/) relay contact information. It can also be used for autodiscovery of Tor relays run by a given entity, if the entity domain is known. It solves the issue that Tor relay contact information is an unidirectional and unverified claim by nature. This well-known URI aims to allow the verification of the unidirectional claim. @@ -23,7 +22,7 @@ organization by pointing to its website: Tor relay contact information field -> * The "tor-relay" URI allows for the verification of that claim by fetching the files containing Tor relay ID(s) under the specified URI, because attackers can not easily place these files at the given location. -* By publishing Tor relay IDs under this URI the website operator claims to operate these relays. +* By publishing Tor relay IDs under this URI the website operator claims to be the responsible entity for these Tor relays. The verification of listed Tor relay IDs only succeeds if the claim can be verified bidirectionally (website -> relay and relay -> website). * This URI is not related to Tor bridges or Tor onion services. @@ -62,7 +61,7 @@ Tor Project Development Mailing List <tor-dev@lists.torproject.org> * [https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt](https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt) * [https://gitweb.torproject.org/torspec.git/tree/cert-spec.txt](https://gitweb.torproject.org/torspec.git/tree/cert-spec.txt) -* [https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/#operatorurl](https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/#operatorurl) +* [https://nusenu.github.io/ContactInfo-Information-Sharing-Specification](https://nusenu.github.io/ContactInfo-Information-Sharing-Specification) * [RFC8615](https://tools.ietf.org/html/rfc8615) diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 8059017..83c3bdc 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -802,7 +802,7 @@ Table of contents: using the current consensus "valid-after" as specified in section [TIME-PERIODS]. - Then, for each node listed in the current consensus with the HSDirV3 flag, + Then, for each node listed in the current consensus with the HSDir flag, we compute a directory index for that node as: hsdir_index(node) = H("node-idx" | node_identity | |