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

nickm at torproject.org nickm at torproject.org
Fri Sep 20 15:10:52 UTC 2013

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
+        "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 and,
    clients switched to using the v2 intro format.
+   The Timestampe (TS) field is no longer used in Tor 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

More information about the tor-commits mailing list