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