commit 1850a1ebe730f206dd05557cf81461d9613c26b9 Author: Roger Dingledine arma@torproject.org Date: Wed Jun 23 04:35:49 2021 -0400

fix some logic errors and typos in specs+proposals --- control-spec.txt | 2 +- proposals/196-transport-control-ports.txt | 2 +- proposals/217-ext-orport-auth.txt | 4 ++-- proposals/328-relay-overload-report.md | 10 +++++----- proposals/329-traffic-splitting.txt | 8 ++++---- rend-spec-v3.txt | 6 +++--- 6 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/control-spec.txt b/control-spec.txt index eac5f92..70f9b20 100644 --- a/control-spec.txt +++ b/control-spec.txt @@ -1044,7 +1044,7 @@ return either a sequence of newline-terminated hex encoded digests, or a "serialized download status" as follows:

- SerializedDownloadSatus = + SerializedDownloadStatus = -- when do we plan to next attempt to download this object? "next-attempt-at" SP ISOTime CRLF -- how many times have we failed since the last success? diff --git a/proposals/196-transport-control-ports.txt b/proposals/196-transport-control-ports.txt index afe6f11..15a1c02 100644 --- a/proposals/196-transport-control-ports.txt +++ b/proposals/196-transport-control-ports.txt @@ -196,7 +196,7 @@ Implemented-In: 0.2.5.2-alpha

5. Authentication

- To defend against cross-protocol attacks on the Extended ORPOrt, + To defend against cross-protocol attacks on the Extended ORPort, proposal 213 defines an authentication scheme that should be used to protect it.

diff --git a/proposals/217-ext-orport-auth.txt b/proposals/217-ext-orport-auth.txt index 1305276..e453ec4 100644 --- a/proposals/217-ext-orport-auth.txt +++ b/proposals/217-ext-orport-auth.txt @@ -131,7 +131,7 @@ Target: 0.2.5.x "ExtORPort authentication server-to-client hash" | ClientNonce | ServerNonce) + ServerNonce is 32 random octets.

- Upon receiving that data, the client computers ServerHash herself and + Upon receiving that data, the client computes ServerHash herself and validates it against the ServerHash provided by the server.

If the server-provided ServerHash is invalid, the client MUST @@ -146,7 +146,7 @@ Target: 0.2.5.x HMAC-SHA256(CookieString, "ExtORPort authentication client-to-server hash" | ClientNonce | ServerNonce)

- Upon receiving that data, the server computers ClientHash herself and + Upon receiving that data, the server computes ClientHash herself and validates it against the ClientHash provided by the client.

Finally, the server replies with: diff --git a/proposals/328-relay-overload-report.md b/proposals/328-relay-overload-report.md index 1ce2bc9..8bcbaa3 100644 --- a/proposals/328-relay-overload-report.md +++ b/proposals/328-relay-overload-report.md @@ -26,9 +26,9 @@ We propose that relays start collecting several metrics (see section 2) reflecting their loads from different component of tor.

Then, we propose that 3 new lines be added to the extra-info document (see -dir-spec.txt, section 2.1.2) if only the overload case arrise. +dir-spec.txt, section 2.1.2) if only the overload case arises.

-This following describes a series of metrics to collect but more might come in +The following describes a series of metrics to collect but more might come in the future and thus this is not an exhaustive list.

# 1.1. General Overload @@ -44,14 +44,14 @@ state" which can be one or many of the following load metrics: - Control port overload (too many messages queued)

The format of the overloaded line added in the extra-info document is as -follow: +follows:

``` "overload-general" SP version SP YYYY-MM-DD HH:MM:SS NL [At most once.] ```

-The timestamp is when at least one metrics was detected. It should always be +The timestamp is when at least one metric was detected. It should always be at the hour and thus, as an example, "2020-01-10 13:00:00" is an expected timestamp. Because this is a binary state, if the line is present, we consider that it was hit at the very least once somewhere between the provided @@ -87,7 +87,7 @@ and BandwidthBurst found in the torrc configuration file.

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 meaningful and to avoid +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.

diff --git a/proposals/329-traffic-splitting.txt b/proposals/329-traffic-splitting.txt index 292f51c..85d704b 100644 --- a/proposals/329-traffic-splitting.txt +++ b/proposals/329-traffic-splitting.txt @@ -22,7 +22,7 @@ Status: Draft

The design space is broken into two orthogonal parts: congestion control algorithms that apply to each path, and traffic scheduling algorithms - that decide when to send packets to send on each path. + that decide which packets to send on each path.

MPTCP specifies 'coupled' congestion control (see [COUPLED]). Coupled congestion control updates single-path congestion control algorithms to @@ -32,10 +32,10 @@ Status: Draft accomplishing this have been proposed and implemented in the Linux kernel.

- Because Tor's congestion control only concerns itself with bottnecks in + Because Tor's congestion control only concerns itself with bottlenecks in Tor relay queues, and not with any other bottlenecks (such as intermediate Internet routers), we can avoid this complexity merely by - specifying that any paths that are constructed SHOULD share any + specifying that any paths that are constructed SHOULD NOT share any relays. In this way, we can proceed to use the exact same congestion control as specified in Proposal 324, for each path.

@@ -465,7 +465,7 @@ Status: Draft

XXX: Note that BLEST uses total_send_window where we use secondary.cwnd in this check. total_send_window is min(recv_win, CWND). But since Tor - does not use receive windows and intead uses stream XON/XOFF, we only + does not use receive windows and instead uses stream XON/XOFF, we only use CWND. There is some concern this may alter BLEST's buffer minimization properties, but since receive window only matter if the application is slower than Tor, and XON/XOFF will cover that case, diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 83c3bdc..2abc732 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -350,7 +350,7 @@ Table of contents: Alex Biryukov, Lasse Øverlier, Ivan Pustogarov, - Paul Syverson + Paul Syverson, Ralf-Philipp Weinmann,

See [ATTACK-REFS] for their papers. @@ -364,7 +364,7 @@ Table of contents: And if this document makes any sense at all, it's thanks to editing help from

- Matthew Finkel + Matthew Finkel, George Kadianakis, Peter Palfrader, Tim Wilson-Brown ("teor"), @@ -2144,7 +2144,7 @@ Table of contents:

where: - PUBKEY is the 32 bytes ed25519 master pubkey of the hidden service. - - VERSION is an one byte version field (default value '\x03') + - VERSION is a one byte version field (default value '\x03') - ".onion checksum" is a constant string - CHECKSUM is truncated to two bytes before inserting it in onion_address