Merge branch 'tor-gitlab/mr/5'

tor-spec.txt

@@ -506,9 +506,11 @@ see tor-design.pdf.
                  Padding bytes SHOULD be set to NUL.
 
    We recommend random padding in RELAY/RELAY_EARLY cells, so that the cell
-   content is unpredictable. See proposal 289 for details. For other
-   cells, TLS authenticates cell content, so randomised padding bytes are
-   redundant.
+   content is unpredictable. See the format of relay cells in section 6.1
+   for detail.
+
+   For other cells, TLS authenticates cell content, so randomized padding
+   bytes are redundant.
 
    Receivers MUST ignore padding bytes.
 
@@ -1030,6 +1032,10 @@ see tor-design.pdf.
    Nodes MUST ignore unrecognized specifiers, and MUST accept multiple
    instances of specifiers other than 'legacy identity'.
 
+   For purposes of indistinguishability, implementations SHOULD send
+   these link specifiers, if using them, in this order: [00], [02], [03],
+   [01].
+
    The relay payload for an EXTEND relay cell consists of:
 
          Address                       [4 bytes]
@@ -1574,7 +1580,8 @@ see tor-design.pdf.
          StreamID                [2 bytes]
          Digest                  [4 bytes]
          Length                  [2 bytes]
-         Data                    [PAYLOAD_LEN-11 bytes]
+         Data                    [Length bytes]
+         Padding                 [PAYLOAD_LEN - 11 - Length bytes]
 
    The relay commands are:
 
@@ -1645,6 +1652,14 @@ see tor-design.pdf.
    handle padding bytes of unencrypted relay cells as they do padding
    bytes for other cell types; see Section 3.
 
+   The 'Padding' field is used to make relay cell contents unpredictable, to
+   avoid certain attacks (see proposal 289 for rationale). Implementations
+   SHOULD fill this field with four zero-valued bytes, followed by as many
+   random bytes as will fit.  (If there are fewer than 4 bytes for padding,
+   then they should all be filled with zero.
+
+   Implementations MUST NOT rely on the contents of the 'Padding' field.
+
    If the RELAY cell is recognized but the relay command is not
    understood, the cell must be dropped and ignored. Its contents
    still count with respect to the digests and flow control windows, though.
@@ -1686,7 +1701,7 @@ see tor-design.pdf.
    Upon receiving this cell, the exit node resolves the address as
    necessary, and opens a new TCP connection to the target port.  If the
    address cannot be resolved, or a connection can't be established, the
-   exit node replies with a RELAY_END cell.  (See 6.4 below.)
+   exit node replies with a RELAY_END cell.  (See 6.3 below.)
    Otherwise, the exit node replies with a RELAY_CONNECTED cell, whose
    payload is in one of the following formats:
 
@@ -1787,9 +1802,16 @@ see tor-design.pdf.
       14 -- REASON_NOTDIRECTORY   (Client sent RELAY_BEGIN_DIR to a
                                    non-directory relay.)
 
-   (With REASON_EXITPOLICY, the 4-byte IPv4 address or 16-byte IPv6 address
-   forms the optional data, along with a 4-byte TTL; no other reason
-   currently has extra data.)
+
+   For most reasons, the format is:
+
+      Reason                      [1 byte]
+
+   For REASON_EXITPOLICY, the format is:
+
+      Reason                      [1 byte]
+      IPv4 or IPv6 address        [4 bytes or 16 bytes]
+      TTL                         [4 bytes]
 
    OPs and ORs MUST accept reasons not on the above list, since future
    versions of Tor may provide more fine-grained reasons.