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

Ryan Hurst <ryan.hurst@globalsign.com> Wed, 11 September 2013 16:20 UTC

Return-Path: <ryan.hurst@globalsign.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8AA21E816E for <tls@ietfa.amsl.com>; Wed, 11 Sep 2013 09:20:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.202
X-Spam-Level:
X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDVipL0jCJN9 for <tls@ietfa.amsl.com>; Wed, 11 Sep 2013 09:19:44 -0700 (PDT)
Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2B17521E813D for <tls@ietf.org>; Wed, 11 Sep 2013 09:19:19 -0700 (PDT)
Received: by mail-yh0-f52.google.com with SMTP id v1so3545829yhn.25 for <tls@ietf.org>; Wed, 11 Sep 2013 09:19:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=globalsign.com; s=google; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=CW27Ym4IxTmglMMGPlvf0q8b40jRRYeo/RgW7BUgXl4=; b=O4ZDCmauhxBhNXxypY82nbLb+Mc2qDvpz50wVD34QxF21uFsowmYV2M0fzfiyqjlHD hg4q7fok7rRLwJyJVR2jd+rspZsb890G1LvSS/ZSr5D93ntnWYKNIw3ifysNfjSfdV34 Us0/aSodiKVQS0NUIXbQ5+8Um/kHs8PjJlkHk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=CW27Ym4IxTmglMMGPlvf0q8b40jRRYeo/RgW7BUgXl4=; b=aIoQEX8wj7JCVqnqGxROBDOxCO+dMe9GOF0akNAjZ6n1XWUilQuH/wYQ8QzbW9Ho7I /H/kGu9vQiQeK9xsTcVZxB7/VmiPqUBxHDPPcdSHRUu2f1llL0QugJsPKQ/RTQvQ4DXq dkrtJyKTHv+V7uXozcDC7pr7e42qdVJxjnD5FOh5jnij5/k02+PGqFdRaPzcoKPBxqOZ 4k5yo8d2LMAK6YO6jBJFEnXugvFCy+Rk+PsEhKD5eSw29lrH2wBQuPi96JgRKo8HMzTx yXfqkCXYrAOvmbPg3Qv7S1sMVO+MWbF04NOKuSMuC980KYHlXhmEZ0IsmovWIJp9AAfY chSw==
X-Gm-Message-State: ALoCoQkibLXvYEz3SczE9SvjxVVKuFXMCET6QfKKY1RN5PStAC4dAB4s1KJlb8SUFaFjoHzW189X
X-Received: by 10.236.171.195 with SMTP id r43mr2180422yhl.56.1378916354477; Wed, 11 Sep 2013 09:19:14 -0700 (PDT)
Received: from [10.215.131.49] (mobile-166-147-082-236.mycingular.net. [166.147.82.236]) by mx.google.com with ESMTPSA id w42sm33505874yhb.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Sep 2013 09:19:12 -0700 (PDT)
References: <CAKDKvuw240Ug4xB3zi2w0y7pUvCwSe0nNFZ2XP2vL-tbtKT0tg@mail.gmail.com> <CALR0uiJ0+yvcuYG69pSaaJntJwta-odJJQRMxQJWgVXKvUp3wQ@mail.gmail.com> <CABcZeBMY+iFgoq8E0hw8yYimqadTYN6CVfy-Ya1tAkbmsigAJQ@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CABcZeBMY+iFgoq8E0hw8yYimqadTYN6CVfy-Ya1tAkbmsigAJQ@mail.gmail.com>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-92561D84-7739-4029-9D31-66A0E1FC071C; protocol="application/pkcs7-signature"
Content-Transfer-Encoding: 7bit
Message-Id: <19AD06BF-648C-43F7-A076-A98CFA0E85C7@globalsign.com>
X-Mailer: iPhone Mail (10B329)
From: Ryan Hurst <ryan.hurst@globalsign.com>
Date: Wed, 11 Sep 2013 09:19:06 -0700
To: Eric Rescorla <ekr@rtfm.com>
Cc: "perpass@ietf.org" <perpass@ietf.org>, "tls@ietf.org" <tls@ietf.org>, Alfredo Pironti <alfredo@pironti.eu>
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Sep 2013 16:20:01 -0000

I have looked at this some, network appliances such as F5s Big IP use a random value instead of time.

I recall seeing some clients also do this but I don't recall which ones.

Basically such a change should be safe.

That said as Russ has pointed out TPSDATE uses this mechanism and though it doesn't solve a broken cryptographic subsystem it is kind of belt and suspenders approach.

Ryan Hurst
Chief Technology Officer
GMO Globalsign

twitter: @rmhrisk
email: ryan.hurst@globalsign.com
phone: 206-650-7926

Sent from my phone, please forgive the brevity.

On Sep 11, 2013, at 9:06 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> Before we discuss mechanisms, it would be good to verify that in general
> clients and servers don't become unhappy if the timestamp is radically
> wrong. Has someone done measurements to verify that this is in fact
> the case at a broad scale?
> 
> -Ekr
> 
> 
> 
> On Wed, Sep 11, 2013 at 9:01 AM, Alfredo Pironti <alfredo@pironti.eu> wrote:
>> I'm in favor of proposal 1, and second the considerations about it;
>> essentially, a broken crypto implementation cannot be fixed by a
>> timestamp.
>> 
>> If proposal 2 (and 3) was to be implemented on a server, it would also
>> make DoS easier, because a cheap ClientHello (even generated with weak
>> randomness) would trigger an extra HMAC computation on the server,
>> with respect to the current server load.
>> 
>> Hence, relying on PRNG on both client and server sides looks like a
>> reasonable way to go. I also don't particularly like the asymmetry
>> that proposal 2 may bring: client generating randomness with HMAC, and
>> servers still using the timestamp in clear.
>> 
>> Cheers,
>> Alfredo
>> 
>> On Wed, Sep 11, 2013 at 5:43 PM, Nick Mathewson <nickm@torproject.org> wrote:
>> > Hi, all.
>> >
>> > Here's something I wrote about removing a fingerprinting opportunity
>> > from the current TLS protocol.  I was going to just send it to the tls
>> > list, but Ben Laurie suggested that I send it to the perpass list as
>> > well.
>> >
>> > I have little standards-body experience; if this ought to turn into an
>> > RFC or something, I'd be happy to write a draft if need be.
>> >
>> >
>> > (Tor currently plans to implement this by patching OpenSSL; any
>> > feedback or advice would be appreciated.  The first three approaches
>> > below are implemented in OpenSSL branches named "no_client_timestamp",
>> > "no_client_timestamp_v2" , and "no_client_timestamp_v3" in the git
>> > repository at https://github.com/nmathewson/openssl .  We have long
>> > shipped our privacy-enhanced browser with a feature like this enabled
>> > through an NSS patch.)
>> >
>> >
>> > ====
>> > SYNOPSIS:
>> >
>> > 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.
>> >
>> >
>> > ACKNOWLEDGEMENTS:
>> >
>> > Thanks to Adam Langley, Ben Laurie, and everybody else who gave me
>> > feedback here.
>> >
>> >
>> > PROBLEM:
>> >
>> > The gmt_unix_time field in the Random field in the TLS handshake
>> > provides a way for an observer to fingerprint clients.
>> >
>> > Despite the late date, much of the world is still not
>> > synchronized to the second via an ntp-like service. This means
>> > that different clients have different views of the current time,
>> > which provides a fingerprint that helps to track and distinguish
>> > them.  This fingerprint is useful for tracking clients as they
>> > move around.  It can also distinguish clients using a single VPN,
>> > NAT, or privacy network.  (Tor's modified firefox avoids this by
>> > not sending the time.)
>> >
>> > Worse, some implementations don't send the current time, but the
>> > process time, or the computer's uptime, both of which are far
>> > more distinguishing than the current time() value.
>> >
>> > The information fingerprint here is strong enough to uniquely
>> > identify some TLS users (the ones whose clocks are hours off).
>> > Even for the ones whose clocks are mostly right (within a second
>> > or two), the field leaks a bit of information, and it only takes
>> > so many bits to make a user unique.
>> >
>> > Of course, I realize that the gmt_unix_time fingerprint is not the
>> > only way to track a typical client as it moves from network to
>> > network, and not the only way to distinguish different clients
>> > behind a NAT.
>> >
>> >
>> >
>> > BACKGROUND: WHY gmt_unix_time IN THE FIRST PLACE?
>> >
>> > According to third-hand reports (and correct me if I'm wrong!)
>> > gmt_unix_time was introduced in SSL 3.0 to prevent complete failure
>> > in cases where the PRNG was completely broken, by making a part of
>> > the Random field that would definitely vary between TLS handshakes.
>> >
>> > I doubt that this goal is really achieved, for two reasons:
>> >
>> >    * On modern desktop environments, it's not really so strange to
>> >      start two or more TLS connections within the same second.  When
>> >      this occurs, the gmt_unix_time fails in its intended purpose of
>> >      preventing repeated Random values.
>> >
>> >    * Nonwithstanding the gmt_unix_time workaround, TLS in general
>> >      does not withstand broken PRNGs.  For one example, if an
>> >      implementation's PRNG is prone to repeating ClientRandom
>> >      values, it is probably prone to repeating those some values as
>> >      ephemeral Diffie-Hellman private values.
>> >
>> > Nevertheless, if the goal of providing unique-looking output
>> >
>> >
>> >
>> > WHY ELSE IS gmt_unix_time USED?
>> >
>> > The consensus among implementors I've asked seems to be that it's
>> > unwise to depend on any particular value or interpretation for the
>> > field.  The TLS 1.2 standard, RFC 5246, says that "Clocks are not
>> > required to be set correctly by the basic TLS protocol; higher-level
>> > or application protocols may define additional requirements."
>> >
>> > Some implementations set the entire gmt_unix_time field randomly;
>> > this appears not to have broken TLS on the internet.
>> >
>> > At least one tool (tlsdate) uses the server-side value of the
>> > field as an authenticated view of the current time.
>> >
>> >
>> >
>> > PROPOSAL 1:
>> >
>> > Declare that implementations MAY replace gmt_unix_time either with
>> > four more random bytes, or four bytes of zeroes.
>> >
>> > Rationale:
>> >    * Some implementations (like TorBrowser) are already doing this
>> >      in practice.
>> >
>> >    * It's sensible and simple.  Implementors are quite unlikely to
>> >      mess it up.
>> >
>> >
>> >
>> > PROPOSAL 2:
>> >
>> > Suppose that we do not accept the argument about the pointlessness
>> > of gmt_unit_time that I make above, and we want to preserve the
>> > security it allegedly provides.
>> >
>> > In that case, we can allow the following approach instead:
>> >
>> > Set the Random field, not to 32 bytes from your PRNG, but to the
>> > HMAC-SHA256 of any high resolution timer that you have, using 32
>> > bytes from your PRNG as a key.  In other words, replace this:
>> >
>> >    Random.gmt_unix_time = time();
>> >    Random.random_bytes = get_random_bytes(28)
>> >
>> > with this:
>> >
>> >    now = hires_time(); // clock_gettime(), or concatenate time()
>> >                        // with a CPU timer, or process
>> >                        // uptime, or whatever.
>> >    key = get_random_bytes(32);
>> >    Random = hmac_sha256(key, now);
>> >
>> > This approach is better than the status quo on the following
>> > counts:
>> >
>> >    * It doesn't leak your view of the current time, assuming that
>> >      your PRNG isn't busted.
>> >
>> >    * It actually fixes the problem that gmt_unix_time purported to
>> >      fix, by using a high-resolution time that's much less likely to
>> >      be used twice.  Even if the PRNG is broken, the value is still
>> >      nonrepeating.
>> >
>> > I do not think this is not worse than the status quo:
>> >
>> >    * It is unpredictable from an attacker's POV, assuming that the
>> >      PRNG works.  (Because an HMAC, even of known data, with an
>> >      unknown random key is supposed to look random).
>> >
>> >
>> > PROPOSAL 3
>> >
>> > As a hybrid alternative, one could set part of the ClientRandom
>> > field (perhaps 12 bytes or so) based on the HMAC of the time, and
>> > the rest of the ClientRandom field based on the PRNG:
>> >
>> >    N = 12
>> >
>> >    now = hires_time();
>> >    key = get_random_bytes(32);
>> >    mac = hmac_sha256(key, now)[0:N];  // First N bytes.
>> >    rand = get_random_bytes(32 - N)
>> >    Random = mac ++ rand               // concatenate.
>> >
>> > But this seems to be getting pointlessly baroque.
>> >
>> >
>> >
>> > CONSIDERATIONS:
>> >
>> > I'd personally suggest proposal 1 (just set the field at random) for
>> > most users.  Yes, it makes things a little worse if your PRNG can
>> > generate repeat values... but nearly everything in cryptography
>> > fails if your PRNG is broken.
>> >
>> >
>> > We might want to apply this fix on clients only.  With a few
>> > exceptions (like hidden services) the server's view of the current
>> > time is not sensitive.
>> >
>> >
>> > Implementors might want to make this feature optional and
>> > on-by-default, just in case some higher-level application protocol
>> > really does depend on it.
>> > _______________________________________________
>> > TLS mailing list
>> > TLS@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tls
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls