diff options
| author | Nick Mathewson <nickm@torproject.org> | 2023-03-22 14:22:28 -0400 |
|---|---|---|
| committer | Nick Mathewson <nickm@torproject.org> | 2023-03-22 14:24:33 -0400 |
| commit | 33308845cec54bfc0096b8ea0339a8ff183aa1b1 (patch) | |
| tree | e7aceb233ef11f8f58bfe7ed6a57865f94dbbc98 /rend-spec-v3.txt | |
| parent | 71ed0ed8312afe313158662b9151228188cce9ee (diff) | |
| download | torspec-33308845cec54bfc0096b8ea0339a8ff183aa1b1.tar.gz torspec-33308845cec54bfc0096b8ea0339a8ff183aa1b1.zip | |
{rend,tor}-spec: clarify linkspec ID multiplicity issues
We were previously a bit unclear on how to handle multiple linkspecs
of type ed25519, and our spec didn't actually permit Tor's current
behavior.
Now we say that both Ed25519 ID and Legacy ID linkspecs MUST appear
at most once in a list of linkspecs, and that parties SHOULD
enforce this.
This is "problem 1" on torspec#193.
Diffstat (limited to 'rend-spec-v3.txt')
| -rw-r--r-- | rend-spec-v3.txt | 11 |
1 files changed, 6 insertions, 5 deletions
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 3f76824..757fc1a 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -238,7 +238,7 @@ Table of contents: LSPEC (Link specifier) [LSLEN bytes] Link specifier types are as described in tor-spec.txt. Every set of - link specifiers MUST include at minimum specifiers of type [00] + link specifiers SHOULD include at minimum specifiers of type [00] (TLS-over-TCP, IPv4), [02] (legacy node identity) and [03] (ed25519 identity key). @@ -1380,7 +1380,7 @@ Table of contents: point section] The link-specifiers is a base64 encoding of a link specifier - block in the format described in BUILDING-BLOCKS. + block in the format described in [BUILDING-BLOCKS] above. As of 0.4.1.1-alpha, services include both IPv4 and IPv6 link specifiers in descriptors. All available addresses SHOULD be @@ -1392,8 +1392,9 @@ Table of contents: recognize; instead, it should use them verbatim in its EXTEND request to the introduction point. - The client MAY perform basic validity checks on the link - specifiers in the descriptor. These checks SHOULD NOT leak + The client SHOULD perform the basic validity checks on the link + specifiers in the descriptor, described in `tor-spec.txt` + section 5.1.2. These checks SHOULD NOT leak detailed information about the client's version, configuration, or consensus. (See 3.3 for service link specifier handling.) @@ -1903,7 +1904,7 @@ Table of contents: The hidden service should handle invalid or unrecognised link specifiers the same way as clients do in section 2.5.2.2. In particular, services - MAY perform basic validity checks on link specifiers, and SHOULD NOT + SHOULD perform basic validity checks on link specifiers, and SHOULD NOT reject unrecognised link specifiers, to avoid information leaks. The ONION_KEY_TYPE field is: |