commit 7cfcf176dcf97ed34c8976e117e15c3ca65c115e Author: Nick Mathewson <nickm@torproject.org> Date: Wed Feb 10 13:07:53 2021 -0500 Add proposal 330-authority-contact.md --- proposals/000-index.txt | 2 + proposals/330-authority-contact.md | 180 +++++++++++++++++++++++++++++++++++++ proposals/BY_INDEX.md | 1 + proposals/README.md | 1 + 4 files changed, 184 insertions(+) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 6851cff..ec40cd3 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -249,6 +249,7 @@ Proposals by number: 326 The "tor-relay" Well-Known Resource Identifier [OPEN] 327 A First Take at PoW Over Introduction Circuits [DRAFT] 328 Make Relays Report When They Are Overloaded [DRAFT] +330 Modernizing authority contact entries [OPEN] Proposals by status: @@ -288,6 +289,7 @@ Proposals by status: 324 RTT-based Congestion Control for Tor 325 Packed relay cells: saving space on small commands 326 The "tor-relay" Well-Known Resource Identifier + 330 Modernizing authority contact entries ACCEPTED: 265 Load Balancing with Overhead Parameters [for 0.2.9.x] 275 Stop including meaningful "published" time in microdescriptor consensus [for 0.3.1.x-alpha] diff --git a/proposals/330-authority-contact.md b/proposals/330-authority-contact.md new file mode 100644 index 0000000..61e05ea --- /dev/null +++ b/proposals/330-authority-contact.md @@ -0,0 +1,180 @@ +``` +Filename: 330-authority-contact.md +Title: Modernizing authority contact entries +Author: Nick Mathewson +Created: 10 Feb 2021 +Status: Open +``` + +This proposal suggests changes to interfaces used to describe a +directory authority, to better support load balancing and +denial-of-service resistance. + +(In an appendix, it also suggests an improvement to the description of +authority identity keys, to avoid a deprecated cryptographic algorithm.) + +# Background + +There are, broadly, three good reasons to make a directory request to a Tor +directory authority: + + - As a relay, to publish a new descriptor. + - As another authority, to perform part of the voting and consensus + protocol. + - As a relay, to fetch a consensus or a set of (micro)descriptors. + +There are some more reasons that are OK-ish: + - as a bandwidth authority or similar related tool running under the + auspices of an authority. + - as a metrics tool, to fetch directory information. + - As a liveness checking tool, to make sure the authorities are running. + +There are also a number of bad reasons to make a directory request to a +Tor directory authority. + + - As a client, to download directory information. (_Clients should + instead use a directory guard, or a fallback directory if + they don't know any directory information at all._) + - As a tor-related application, to download directory information. + (_Such applications should instead run a tor client, which can + maintain an up-to-date directory much more efficiently._) + + +Currently, Tor provides two mechanisms for downloading and uploading directory +information: the DirPort, and the BeginDir command. A DirPort is an +HTTP port on which directory information is served. The BeginDir +command is a relay command that is used to send an HTTP stream directly +over a Tor circuit. + +Historically, we used DirPort for all directory requests. Later, when +we needed encrypted or anonymous directory requests, we moved to a +"Begin-over-tor" approach, and then to BeginDir. We still use the +DirPort directly, however, when relays are connecting to authorities to +publish descriptors or download fresh directories. We also use it for +voting. + +This proposal suggests that instead of having only a single DirPort, +authorities should be able to expose a separate contact point for each +supported interaction above. By separating these contact points, we can +impose separate access controls and rate limits on each, to improve the +robustness of the consensus voting process. + +Eventually, separate contact points will allow us do even more: we'll be +able to have separate implementations for the upload and download +components of the authorities, and keep the voting component mostly +offline. + +# Adding contact points to authorities + +Currently, for each directory authority, we ship an authority entry. +For example, the entry describing tor26 is: + + "tor26 orport=443 " + "v3ident=14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4 " + "ipv6=[2001:858:2:2:aabb:0:563b:1526]:443 " + "86.59.21.38:80 847B 1F85 0344 D787 6491 A548 92F9 0493 4E4E B85D", + +We extend these lines with optional contact point elements as follows: + + - `upload=http://IP:port/` A location to publish router descriptors. + - `download=http://IP:port/` A location to use for caches when fetching + router descriptors. + - `vote=http://IP:port/` A location to use for authorities when voting. + +Each of these contact point elements can appear more than once. If it does, +then it describes multiple valid contact points for a given purpose; +implementations MAY use any of the contact point elements that they recognize +for a given authority. + +Implementations SHOULD ignore url schemas that they do not recognize, and +SHOULD ignore hostnames addresses that appear in the place of the IP elements +above. (This will make it easier for us to extend these lists in the future.) + +If there is no contact point element for a given type, then implementations +should fall back to using the main IPv4 addr:port, and/or the IPv6 addr:port +if available. + +As an extra rule: If more than one authority lists the same upload +point, then uploading a descriptor to that upload point counts as having +uploaded it to all of those authorities. (This rule will allow multiple +authorities to share an upload point in the future, if they decide to do +so. We do not need a corresponding rules for voting or downloading, +since every authority participates in voting directly, and since there +is no notion of "downloading from each authority.") + +# Authority-side configuration + +We add a few flags to DirPort configuration, indicating what kind of requests +are acceptable. + + - `no-voting` + - `no-download` + - `no-upload` + +These flags remove a given set of possible operations from a given +DirPort. So for example, an authority might say: + + DirPort 9030 no-download no-upload + DirPort 9040 no-voting no-upload + DirPort 9050 no-voting no-download + +We can also allow "upload-only" as an alias for "no-voting no-download", and so on. + +Note that authorities would need to keep a legacy dirport around until +all relays have upgraded. + +# Bridge authorities + +This proposal does not yet apply to bridge authorities, since neither +clients nor bridges connect to bridge authorities over HTTP. A later +proposal may add a schema that can be used to describe contacting to a +bridge authority via BEGINDIR. + +# Example uses + +## Example setup: Simple access control and balancing. + +Right now the essential functionality of authorities is sometimes +blocked by getting too much load from directory downloads by +non-relays. To address this we can proceed as follows. We can have +each relay authority open four separate dirports: One for publishing, +one for voting, one for downloading, and one legacy port. +These can be rate-limited separately, and requests sent to the wrong port +can be rejected. We could additionally prioritize voting, then uploads, +then downloads. This could be done either within Tor, or with other IP +shaping tools. + +## Example setup: Full authority refactoring + +In the future, this system lets us get fancier with our authorities and +how they are factored. For example, as in proposal 257, an authority could +run upload services, voting, and download services all at +separate locations. + +The authorities themselves would be the only ones that needed to use +their voting protocol. The upload services (run on the behalf of +authorities or groups of authorities) could receive descriptors and do +initial testing on them before passing them on to the authorities. The +authorities could then vote with one another, and push the resulting +consensus and descriptors to the download services. This would make the +download services primarily responsible for serving directory +information, and have them take all the load. + + +# Appendix: Cryptographic extensions to authority configuration + +The 'v3ident' element, and the relay identity fingerprint in authority +configuration, are currently both given as SHA1 digests of RSA keys. SHA1 is +currently deprecated: even though we're only relying on second-preimage +resistance, we should migrate away. + +With that in mind, we're adding two more fields to the authority entries: + + - `ed25519-id=BASE64` The ed25519 identity of a the authority when it + acts as a relay. + - `v3ident-sha3-256=HEX` The SHA3-256 digest of the authority's v3 signing + key. + +(We use base64 here for the ed25519 key since that's what we use +elsewhere.) + diff --git a/proposals/BY_INDEX.md b/proposals/BY_INDEX.md index 3d80c1c..18d81a0 100644 --- a/proposals/BY_INDEX.md +++ b/proposals/BY_INDEX.md @@ -246,4 +246,5 @@ Below are a list of proposals sorted by their proposal number. See * [`326-tor-relay-well-known-uri-rfc8615.md`](/proposals/326-tor-relay-well-known-uri-rfc8615.md): The "tor-relay" Well-Known Resource Identifier [OPEN] * [`327-pow-over-intro.txt`](/proposals/327-pow-over-intro.txt): A First Take at PoW Over Introduction Circuits [DRAFT] * [`328-relay-overload-report.md`](/proposals/328-relay-overload-report.md): Make Relays Report When They Are Overloaded [DRAFT] +* [`330-authority-contact.md`](/proposals/330-authority-contact.md): Modernizing authority contact entries [OPEN] diff --git a/proposals/README.md b/proposals/README.md index 44996ad..24374bb 100644 --- a/proposals/README.md +++ b/proposals/README.md @@ -39,6 +39,7 @@ for discussion. * [`324-rtt-congestion-control.txt`](/proposals/324-rtt-congestion-control.txt): RTT-based Congestion Control for Tor * [`325-packed-relay-cells.md`](/proposals/325-packed-relay-cells.md): Packed relay cells: saving space on small commands * [`326-tor-relay-well-known-uri-rfc8615.md`](/proposals/326-tor-relay-well-known-uri-rfc8615.md): The "tor-relay" Well-Known Resource Identifier +* [`330-authority-contact.md`](/proposals/330-authority-contact.md): Modernizing authority contact entries ## ACCEPTED proposals: slated for implementation