Re: [TLS] Let's remove gmt_unix_time from TLS (Martin Rex) Wed, 11 September 2013 17:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C543A21F9CBF; Wed, 11 Sep 2013 10:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X6-D2htg+pBb; Wed, 11 Sep 2013 10:41:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2151621F9A59; Wed, 11 Sep 2013 10:41:36 -0700 (PDT)
Received: from by (26) with ESMTP id r8BHfZO7023037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Sep 2013 19:41:35 +0200 (MEST)
In-Reply-To: <>
To: Nick Mathewson <>
Date: Wed, 11 Sep 2013 19:41:35 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
From: (Martin Rex)
X-SAP: out
Cc:, "" <>
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Sep 2013 17:41:43 -0000

Nick Mathewson wrote:
> ====
> In TLS as currently specified, clients and servers each send their
> current view of "the time" in the clear as part of their handshake.
> This provides a fingerprint that can track users in spite of other
> attempts to make them untrackable.  I propose several ways to stop
> doing sending this cleartext timestamp; some trivial and some more
> complex.

I would really appreciate a different approach to the underlying
issue, and less throwing of smoke grenades here.

If you're worried about being slightly "distinguishable" from some
other clients, then there are a lot more reliable identifiers available
in the average TLS handshake, so claiming that sending the actual local
time in ClientHello.Random.gmt_unix_time creates a severe fingerprinting
issue and sending random will solve the fingerprinting issue, is
bordering on lame for >99% of the clients.

Most of the time, repeated requests of the same TLS client can be
identified by the network connection having the same client IP address,
the TLS session proposed for resumption in ClientHello.session_id
or maybe someone still using TLS session tickets (rfc5077).

So rather than pointing to ClientHello.Random.gmt_unix_time as a
and claiming there would be a simple fix, one will likely have to
create and go through a long list of issues to determine which
features facilitate fingerprinting and tracking (cipher suites
and many TLS extensions (TLS caching extension, signature algorithms,
Next protocol negotiation, supported elliptic curves, etc.) may
all help in distinguishing clients, and would also have to be
taken care of.