torproject/torspec
1
0
Fork 0
mirror of https://github.com/torproject/torspec.git synced 2025-02-18 15:49:34 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

{rend,tor}-spec: clarify linkspec ID multiplicity issues

Browse Source 
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.
This commit is contained in:
Nick Mathewson 2023-03-22 14:22:28 -04:00
parent 71ed0ed831
commit 33308845ce
2 changed files with 10 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
rend-spec-v3.txt
View File

@ -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:

6
tor-spec.txt
View File

@ -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