Hi isis,
On 14 Dec 2017, at 12:46, isis agora lovecruft isis@torproject.org wrote:
6.1. New Subprotocols and Subprotocol Versions
This proposal introduces, following prop#264, the following new subprotocol numbers and their uses.
6.1.1. Relay Subprotocol
"Relay 3" -- The OP supports all of "Relay 2", plus support for CREATE2V and CREATED2V cells and their above specification for link-layer authentication specifiers.
We usually specify that the numbers will be allocated when the proposal is merged. That avoids gaps in the numbering, and weird semantics like "4 doesn't support 3".
In particular, an upcoming IPv6 proposal will need a new Relay protover, and it might get merged in 0.3.3.
6.1.2. Link Subprotocol
"Link 5": The OP supports all of "Link 1-4", plus support for the new EXTEND2 semantics. Namely, it understands that an EXTEND2 cell whose "hlen" field is greater than 505 will be followed by further "hdata" in fragmented EXTEND2 cells which MUST follow. It also understands that the following combination of EXTEND2 payload specifiers indicates that the cell is a continuation of the earlier payload portions: nspec = 0; htype = 0xffff; hlen = 0;
Link version 5 is link padding, which was merged in 0.3.2: https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n571
6.1.3. Handshake Subprotocol
Additionally, we introduce a new subprotocol, "Handshake" and the following number assignments for previously occuring instances:
"Handshake 1" -- The OP supports the TAP handshake. "Handshake 2" -- The OP supports the ntor handshake.We also reserve the following assignments for future use:
"Handshake 3" -- The OP supports the "hybrid+null" ntor-like handshake from prop#269. "Handshake 4" -- The OP supports a(n as yet unspecified) post-quantum secure hybrid handshake, that is, the "hybrid+null" handshake from "Handshake 3", except with "null" part replaced with another (as yet unspecified) protocol to be composed with the ntor-like ECDH-based handshake.Further handshakes MUST be specified with "Handshake" subprotocol numbers, and MUST NOT be specified with "Relay" subprotocol numbers. The "Relay" subprotocol SHALL be used in the future to denote changes to handshake protocol handling of CREATE* and EXTEND* cells, i.e. CREATE, CREATED, CREATE_FAST, CREATED_FAST, CREATE2, CREATED2, CREATE2V, CREATED2V, EXTEND, EXTENDED, EXTEND2, and EXTENDED2.
Thus, "Handshake 1" is taken to be synonymous with "Relay 1", and likewise "Handshake 2" is with "Relay 2".
Since this is a new protover field, it's ok to reserve numbers :-)
6.2. Subprotocol Recommendations
After the subprotocol additions above, we change to recommending the following in the consensus:
recommended-client-protocols […] Link=5 Relay=3 Handshake=2 recommended-relay-protocols […] Link=5 Relay=3 Handshake=2
I don't think we will want to jump straight to recommending the highest protovers.
Is there a reason for this? Does it lead to warnings on clients or relays?
required-client-protocols […] Link=4-5 Relay=2-3 Handshake=1-2 required-relay-protocols […] Link=3-5 Relay=1-3 Handshake=1-2
T