diff options
Diffstat (limited to 'rend-spec-v3.txt')
| -rw-r--r-- | rend-spec-v3.txt | 29 |
1 files changed, 23 insertions, 6 deletions
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 3f76824..4a12343 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -238,9 +238,10 @@ 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). + identity key). Sets of link specifiers without these three types + SHOULD be rejected. As of 0.4.1.1-alpha, Tor includes both IPv4 and IPv6 link specifiers in v3 onion service protocol link specifier lists. All available @@ -1380,7 +1381,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,11 +1393,20 @@ 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.) + When connecting to the introduction point, the client SHOULD send + this list of link specifiers verbatim, in the same order as given + here. + + The client MAY reject the list of link specifiers if it is + inconsistent with relay information from the directory, but SHOULD + NOT modify it. + "onion-key" SP "ntor" SP key NL [Exactly once per introduction point] @@ -1903,8 +1913,15 @@ 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 list of link specifiers received here SHOULD either be rejected, or + sent verbatim when extending to the rendezvous point, in the same order + received. + + The service MAY reject the list of link specifiers if it is + inconsistent with relay information from the directory, but SHOULD + NOT modify it. The ONION_KEY_TYPE field is: |