Merge proposal 264 to dir-spec and tor-spec

Signed-off-by: David Goulet <dgoulet@torproject.org>

1 files changed, 82 insertions, 0 deletions

diff --git a/dir-spec.txt b/dir-spec.txt
index 2417dd0..c701842 100644
--- a/dir-spec.txt
+++ b/dir-spec.txt
@@ -731,6 +731,32 @@
        Present if the router accepts "tunneled" directory requests using a
        BEGIN_DIR cell over the router's OR port.
 
+   "proto" SP Entries NL
+
+       [At most one.]
+
+       Entries =
+       Entries = Entry
+       Entries = Entry SP Entries
+
+       Entry = Keyword "=" Values
+
+       Values = Value
+       Values = Value "," Values
+
+       Value = Int
+       Value = Int "-" Int
+
+       Int = NON_ZERO_DIGIT
+       Int = Int DIGIT
+
+       Each 'Entry' in the "proto" line indicates that the Tor relay supports
+       one or more versions of the protocol in question.  Entries should be
+       sorted by keyword.  Values should be numerically ascending within each
+       entry.  (This implies that there should be no overlapping ranges.)
+       Ranges should be represented as compactly as possible. Ints must be no
+       more than 2^32 - 1.
+
 2.1.2. Extra-info document format
 
    Extra-info documents consist of the following items:
@@ -1425,6 +1451,11 @@
         Implementations MUST ignore "id" lines with unrecognized
         key-types in place of "rsa1024" or "ed25519"
 
+     "pr" SP Entries NL
+
+        [At most once.]
+
+        The "proto" element as specified in section 2.1.1.
 
    (Note that with microdescriptors, clients do not learn the RSA identity of
    their routers: they only learn a hash of the RSA identity key.  This is
@@ -1733,6 +1764,27 @@
         Value is the actual shared random value encoded in base64. NumReveals
         is the number of commits used to generate this SRV.
 
+    "recommended-relay-protocols" SP Entries NL
+    "required-relay-protocols" SP Entries NL
+    "recommended-client-protocols" SP Entries NL
+    "required-client-protocols" SP Entries NL
+
+        [At most once for each.]
+
+        The "proto" element as specified in section 2.1.1.
+
+        To vote on these entries, a protocol/version combination is included
+        only if it is listed by a majority of the voters.
+
+        These lines should be voted on.  A majority of votes is sufficient to
+        make a protocol un-supported. and should require a supermajority of
+        authorities (2/3) to make a protocol required.  The required protocols
+        should not be torrc-configurable, but rather should be hardwired in
+        the Tor code.
+
+        The tor-spec.txt section 9 details how a relay and a client should
+        behave when they encounter these lines in the consensus.
+
     "params" SP [Parameters] NL
 
         [At most once]
@@ -2010,6 +2062,19 @@
         descriptors if they would cause "v" lines to be over 128 characters
         long.
 
+    "pr" SP Entries NL
+
+        [At most once.]
+
+        The "proto" family element as specified in section 2.1.1.
+
+        During voting, authorities copy these lines immediately below the "v"
+        lines. When a descriptor does not contain a "proto" entry, the
+        authorities should reconstruct it using the approach described below
+        in section D. They are included in the consensus using the same rules
+        as currently used for "v" lines, if a sufficiently late consensus
+        method is in use.
+
     "w" SP "Bandwidth=" INT [SP "Measured=" INT] [SP "Unmeasured=1"] NL
 
         [At most once.]
@@ -2575,6 +2640,7 @@
      "22" -- Instantiates Ed25519 voting algorithm correctly.
      "23" -- Adds shared randomness protocol data.
      "24" -- No longer lists routers that are not Valid in the consensus.
+     "25" -- Vote on recommended-protocols and required-protocols.
 
    Before generating a consensus, an authority must decide which consensus
    method to use.  To do this, it looks for the highest version number
@@ -3528,3 +3594,19 @@ C. Converting a curve25519 public key to an ed25519 public key
    feed it to the ed25519 public key generation algorithm, and see
    what the sign is.
 
+D. Inferring missing proto lines.
+
+   The directory authorities no longer allow versions of Tor before
+   0.2.4.18-rc.  But right now, there is no version of Tor in the consensus
+   before 0.2.4.19.  Therefore, we should disallow versions of Tor earlier
+   than 0.2.4.19, so that we can have the protocol list for all current Tor
+   versions include:
+
+     Cons=1-2 Desc=1-2 DirCache=1 HSDir=1 HSIntro=3 HSRend=1-2 Link=1-4
+     LinkAuth=1 Microdesc=1-2 Relay=1-2
+
+   For Desc, Tor versions before 0.2.7.stable should be taken to have Desc=1
+   and versions 0.2.7.stable or later should have Desc=1-2.
+
+   For Microdesc and Cons, Tor versions before 0.2.7.stable should be taken to
+   support version 1; 0.2.7.stable and later should have 1-2.