This is an automated email from the git hooks/post-receive script.
dgoulet pushed a change to branch main in repository torspec.
from 71ed0ed Merge remote-tracking branch 'tor-gitlab/mr/119' new 3330884 {rend,tor}-spec: clarify linkspec ID multiplicity issues new 1aa3a83 rend-spec: Clarify that linkspec lists should be used verbatim. new 0b19f21 rend-spec: Clarify that IPv4, RSA-ID and Ed25519-ID are mandatory for now. new 70ca4e9 rend-spec: clarify how dir info may be used to confirm linkspecs
The 4 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference.
Summary of changes: rend-spec-v3.txt | 29 +++++++++++++++++++++++------ tor-spec.txt | 6 ++++-- 2 files changed, 27 insertions(+), 8 deletions(-)
This is an automated email from the git hooks/post-receive script.
dgoulet pushed a commit to branch main in repository torspec.
commit 33308845cec54bfc0096b8ea0339a8ff183aa1b1 Author: Nick Mathewson nickm@torproject.org AuthorDate: Wed Mar 22 14:22:28 2023 -0400
{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. --- rend-spec-v3.txt | 11 ++++++----- tor-spec.txt | 6 ++++-- 2 files changed, 10 insertions(+), 7 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: diff --git a/tor-spec.txt b/tor-spec.txt index 34a3b44..8f30624 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -1128,7 +1128,9 @@ see tor-design.pdf. be listed.
Nodes MUST ignore unrecognized specifiers, and MUST accept multiple - instances of specifiers other than 'legacy identity'. + instances of specifiers other than 'legacy identity' and + 'Ed25519 identity'. (Nodes SHOULD reject link specifier lists + that include multiple instances of either one of those specifiers.)
For purposes of indistinguishability, implementations SHOULD send these link specifiers, if using them, in this order: [00], [02], [03], @@ -1154,7 +1156,7 @@ see tor-design.pdf. target OR did not prove its ownership of any such identity key. If only one identity key is provided, but the extending OR knows the other (from directory information), then the OR SHOULD also - enforce that key. + enforce the key in the directory.
If an extending OR has a channel with a given Ed25519 ID and RSA identity, and receives a request for that Ed25519 ID and a
This is an automated email from the git hooks/post-receive script.
dgoulet pushed a commit to branch main in repository torspec.
commit 1aa3a8316a860318cfcdd150eae7904a27bb321f Author: Nick Mathewson nickm@torproject.org AuthorDate: Wed Mar 22 14:26:56 2023 -0400
rend-spec: Clarify that linkspec lists should be used verbatim.
This resolved "problem 2" from torspec#193. --- rend-spec-v3.txt | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 757fc1a..d1f7618 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -1398,6 +1398,10 @@ Table of contents: 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. + "onion-key" SP "ntor" SP key NL
[Exactly once per introduction point] @@ -1906,6 +1910,9 @@ Table of contents: the same way as clients do in section 2.5.2.2. In particular, services 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 ONION_KEY_TYPE field is:
This is an automated email from the git hooks/post-receive script.
dgoulet pushed a commit to branch main in repository torspec.
commit 0b19f2114ba690cdb92e54f66cc9c518dea6581a Author: Nick Mathewson nickm@torproject.org AuthorDate: Wed Mar 22 14:28:28 2023 -0400
rend-spec: Clarify that IPv4, RSA-ID and Ed25519-ID are mandatory for now.
We can make these non-mandatory in the future if we want, using a consensus flag. --- rend-spec-v3.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index d1f7618..4ba88d7 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -240,7 +240,8 @@ Table of contents: Link specifier types are as described in tor-spec.txt. Every set of 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
This is an automated email from the git hooks/post-receive script.
dgoulet pushed a commit to branch main in repository torspec.
commit 70ca4e9dcb2b37e1fa68a3cdac56dfe244e54ab1 Author: Nick Mathewson nickm@torproject.org AuthorDate: Wed Mar 22 14:30:22 2023 -0400
rend-spec: clarify how dir info may be used to confirm linkspecs
Specifically, you can look at the directory to see if somebody is lying about a relay (mismatched IDs, etc), but you can't modify the list of linkspecs. --- rend-spec-v3.txt | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt index 4ba88d7..4a12343 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -1403,6 +1403,10 @@ Table of contents: 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] @@ -1915,6 +1919,10 @@ Table of contents: 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:
[01] NTOR: ONION_KEY is 32 bytes long.
tor-commits@lists.torproject.org
-
gitolite role