[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
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
@@ -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
@@ -3,7 +3,8 @@ Title: Stop sending client timestamps
Authors: Nick Mathewson
Created: 22 August 2013
@@ -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.)
@@ -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
@@ -301,7 +301,8 @@
- 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
@@ -627,8 +627,10 @@ see tor-design.pdf.
- the NUL terminated ASCII string:
"Tor V3 handshake TLS cross-certification"
- 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