Re: [TLS] [perpass] Let's remove gmt_unix_time from TLS

Stephen Farrell <> Thu, 12 September 2013 08:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C54621E819C; Thu, 12 Sep 2013 01:57:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D78rxCz9yLOI; Thu, 12 Sep 2013 01:57:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 12B6D21E8194; Thu, 12 Sep 2013 01:57:41 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97CD9BE8F; Thu, 12 Sep 2013 09:57:39 +0100 (IST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ik0FrTZwrhCl; Thu, 12 Sep 2013 09:57:39 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 777FBBE8A; Thu, 12 Sep 2013 09:57:39 +0100 (IST)
Message-ID: <>
Date: Thu, 12 Sep 2013 09:57:39 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Nick Mathewson <>,
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc:, "" <>
Subject: Re: [TLS] [perpass] 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: Thu, 12 Sep 2013 08:57:47 -0000

Hi Nick, Martin,

On 09/12/2013 04:51 AM, Nick Mathewson wrote:
> On Wed, Sep 11, 2013 at 1:41 PM, Martin Rex <> wrote:
>> 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.
> I assume good faith on your part; please do the favor of assuming good
> faith on mine.

I think its fair to say that Martin is not renowned for
taking a laid-back zen-like approach when making his
almost-always-good technical contributions:-)

But I didn't see him questioning good faith, I interpret
him as asking (forcefully:-) why this change is worth

(And that's a common pattern actually: someone says "if we
do X that'll make privacy a bit better" and someone else
says "but there are so many other ways to leak private
info, why bother just doing X?")

>> 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.
> Indeed, I never said this was a "severe" issue, or that it was the
> only issue you need to solve to solve fingerprinting.  I said: "This
> provides a fingerprint that can track users in spite of other attempts
> to make them untrackable."
> I know that reading perpass, one expects proposals to fundamentally
> transform the Internet to make it more secure.  

Well, boiling oceans is definitely not the intent of this list.
My guess is that overbroad proposals will get the (lack of)
attention they deserve and will wither on the vine.

> This is not such a
> fundamental transformation. This is a little simple change to fix a
> little simple little problem.

I agree. And seems like a worthwhile one too. BTW, since
the TLS list discussion is up and running, I don't think
there's a need to cc perpass more for this. It was a good
idea to bring it here, but I suspect for this one, we can
let the TLS wg fire ahead and get someone to write up an
I-D if one is needed for this. (My guess is it'd be useful
to have a nice short RFC that updates the relevant bit of
5246 and says why.)

> Of such simple little problems, client linkability is made.
>> 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.
> That's all true; disabling gmt_unix_time is by no means sufficient to
> make multiple TLS clients look the same on the wire, or to prevent an
> observer distinguishing TLS instances.
> In Tor's case, we mitigate this by disabling some TLS features,
> specifying required values for others, rotating some identifiers more
> frequently than most implementations, and shipping all of our clients
> with the same crypto libraries.  Most of the fingerprinting issues in
> TLS can be ameliorated, for a single application, by defining a
> profile that all of that application's users should share.

I think that'd be a fine thing to document (and worthy of a
separate thread on the perpass list). Any chance we could get
that done? (Where "that" == document the implementation steps
to reduce fingerprinting opportunities as outlined above.)
I think it'd be really useful for folks doing other protocol
work to have an example of how its been done for Tor so they
could copy some of the relevant techniques when developing
other protocols. Ping me offlist if you'd like some help with
writing it up as an I-D and I can try find someone to help,
or if you've the energy just write it up and shoot it out
and I can help figure out how best to get it turned into an
RFC. If its already written up elsewhere then a pointer would
be good regardless.


> My issue here right now that, even *after* taking all these
> precautions, the gmt_unix_time issue remains, and the TLS 1.2 RFC
> doesn't make it optional.  Come heck or high water, Tor is going to
> stop sending gmt_unix_time unless we find a really excellent reason to
> send it.  We'd like to replace it with the best alternative we can. I
> sent all the alternatives I could think of, because:
>   1) I would like future versions of the TLS RFC to not require gmt_unix_time.
>   2) I would like to know whether there's a truly legit reason to send
> gmt_unx_time.
>   3) I would like to know the best thing to do instead of gmt_unix_time.
> (The IP address issue is important too, but not overriding here. The
> issue here is that even after a client has changed its IP addresses
> either through moving around the network or going behind a NAT or VPN
> or by using an IP anonymization service, this fingerprint remains.)