[tor-commits] [torspec/master] Merge proposal 222 (eliminate timestamps) into the specifications

[nickm at torproject.org]

commit 6c974c54f190e9e0d75d37ec999f6a354d9fbc36
Author: Nick Mathewson <nickm at torproject.org>
Date:   Wed Sep 18 11:27:34 2013 -0400

    Merge proposal 222 (eliminate timestamps) into the specifications
    
    Also update it with actual decisions and parameters.
---
 dir-spec.txt                               |    7 +++++++
 proposals/222-remove-client-timestamps.txt |   25 ++++++++++++++++---------
 rend-spec.txt                              |    9 ++++++++-
 tor-spec.txt                               |    6 ++++--
 4 files changed, 35 insertions(+), 12 deletions(-)

diff --git a/dir-spec.txt b/dir-spec.txt
index 7222a3b..538170e 100644
--- a/dir-spec.txt
+++ b/dir-spec.txt
@@ -1417,6 +1417,13 @@
         entry for a router that isn't based on at least three
         measurements.
 
+        "Support022HiddenServices" -- Used to implement a mass switch-over
+        from sending timestamps to hidden services by default to sending
+        no timestamps at all.  If this option is absent, or is set to 1,
+        clients with the default configuration send timestamps; otherwise,
+        they do not.
+        Min: 0, Max: 1. Default: 1.
+
    The authority section of a vote contains the following items, followed
    in turn by the authority's current key certificate:
 
diff --git a/proposals/222-remove-client-timestamps.txt b/proposals/222-remove-client-timestamps.txt
index dd84bf2..7cd9cc5 100644
--- a/proposals/222-remove-client-timestamps.txt
+++ b/proposals/222-remove-client-timestamps.txt
@@ -3,7 +3,8 @@ Title: Stop sending client timestamps
 Authors: Nick Mathewson
 Created: 22 August 2013
 Target: 0.2.5.x
-Status: Open
+Status: Closed
+Implemented-In: 0.2.4.??
 
 0. Summary
 
@@ -46,12 +47,14 @@ Status: Open
 
    The AUTHENTICATE cell is not ordinarily sent by clients. It
    contains an 8-byte timestamp and a 16-byte random value.
-   Instead, let's replace both with a 24-byte (truncated) HMAC of
-   the current time, using a random key.
+   Instead, let's just send 24 bytes or random value.
 
-   This will achieve the goal of including a timestamp in the
-   cell (preventing replays even in the presence of bad entropy),
-   while at the same time not including the time here.
+   (An earlier version of this proposal suggested that we replace
+   them both with a 24-byte (truncated) HMAC of the current time,
+   using a random key, in an attempt to retain the allegedly
+   desirable property of avoiding nonce duplication in the event of
+   a bad RNG. But really, a Tor process with a bad RNG is not going
+   to get security in any case, so let's KISS.)
 
 2.3. TLS
 
@@ -89,7 +92,7 @@ Status: Open
 
   Hidden service descriptors include a publication time.  I
   propose that we round this time down to the nearest N minutes,
-  perhaps for N=30.
+  where N=60.
 
 4.2. INTRODUCE2 cell timestamp
 
@@ -102,8 +105,12 @@ Status: Open
   0.2.2.x (and really, no hidden services should be running on
   0.2.2.x!), we can simply send 0 instead.  (See ticket #7803).
 
-  This might be a good place to use a consensus parameter, so
-  that a large number of clients switch at the same time.
+  We can control this behavior with a consensus parameter
+  (Support022HiddenServices) and a tristate (0/1/auto) torrc option of
+  the same name.
+
+  When the timestamp is not completely disabled, it should be
+  rounded to the closest 10 minutes.
 
   I claim this would be suitable for backport to 0.2.4.
 
diff --git a/rend-spec.txt b/rend-spec.txt
index ca40fb5..ebaf4e8 100644
--- a/rend-spec.txt
+++ b/rend-spec.txt
@@ -301,7 +301,8 @@
 
        [Exactly once]
 
-       A timestamp when this descriptor has been created.
+       A timestamp when this descriptor has been created.  It should be
+       rounded down to the nearest hour.
 
      "protocol-versions" SP version-string NL
 
@@ -668,6 +669,12 @@
    v1, and v2 since 0.1.1.x. As of Tor 0.2.0.7-alpha and 0.1.2.18,
    clients switched to using the v2 intro format.
 
+   The Timestampe (TS) field is no longer used in Tor 0.2.3.9-alpha and
+   later.  Clients MAY refrain from sending it; see the
+   "Support022HiddenServices" parameter in dir-spec.txt. Clients SHOULD
+   NOT send a precise timestamp, and should instead round to the nearest
+   10 minutes.
+
 1.9. Introduction: From the Introduction Point to Bob's OP
 
    If the Introduction Point recognizes PK_ID as a public key which has
diff --git a/tor-spec.txt b/tor-spec.txt
index 8471bff..5561201 100644
--- a/tor-spec.txt
+++ b/tor-spec.txt
@@ -627,8 +627,10 @@ see tor-design.pdf.
            - the NUL terminated ASCII string:
              "Tor V3 handshake TLS cross-certification"
           [32 octets]
-       TIME: The time of day in seconds since the POSIX epoch. [8 octets]
-       RAND: A 16 byte value, randomly chosen by the initiator [16 octets]
+       RAND: A 24 byte value, randomly chosen by the initiator.  (In an
+         imitation of SSL3's gmt_unix_time field, older versions of Tor
+         sent an 8-byte timestamp as the first 8 bytes of this field;
+         new implementations should not do that.) [24 octets]
        SIG: A signature of a SHA256 hash of all the previous fields
          using the initiator's "Authenticate" key as presented.  (As
          always in Tor, we use OAEP-MGF1 padding; see tor-spec.txt