[tor-dev] Proposal 249 updated

[teor]

Hi isis,

> On 14 Dec 2017, at 12:46, isis agora lovecruft <isis at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171215/d7cda7e1/attachment.html>