Re: [TLS] Let's remove gmt_unix_time from TLS
Xiaoyong Wu <X.Wu@F5.com> Wed, 11 September 2013 18:23 UTC
Return-Path: <X.Wu@F5.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 C465811E81F2; Wed, 11 Sep 2013 11:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 0cBwXX7tGCeG; Wed, 11 Sep 2013 11:23:36 -0700 (PDT)
Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 817DA11E81D2; Wed, 11 Sep 2013 11:23:36 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.90,885,1371081600"; d="scan'208,217"; a="81622733"
Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 11 Sep 2013 18:23:35 +0000
Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS03.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Wed, 11 Sep 2013 11:23:34 -0700
From: Xiaoyong Wu <X.Wu@F5.com>
To: Ryan Hurst <ryan.hurst@globalsign.com>, Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [TLS] Let's remove gmt_unix_time from TLS
Thread-Index: AQHOrwriSahGkkxdq02hAgcmqMDbYJnA2WdA
Date: Wed, 11 Sep 2013 18:23:33 +0000
Message-ID: <E774C81546D66E429BF56B1474C7EBBA010E33002E@SEAEMBX01.olympus.F5Net.com>
References: <CAKDKvuw240Ug4xB3zi2w0y7pUvCwSe0nNFZ2XP2vL-tbtKT0tg@mail.gmail.com> <CALR0uiJ0+yvcuYG69pSaaJntJwta-odJJQRMxQJWgVXKvUp3wQ@mail.gmail.com> <CABcZeBMY+iFgoq8E0hw8yYimqadTYN6CVfy-Ya1tAkbmsigAJQ@mail.gmail.com> <19AD06BF-648C-43F7-A076-A98CFA0E85C7@globalsign.com>
In-Reply-To: <19AD06BF-648C-43F7-A076-A98CFA0E85C7@globalsign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.16.250]
Content-Type: multipart/alternative; boundary="_000_E774C81546D66E429BF56B1474C7EBBA010E33002ESEAEMBX01olym_"
MIME-Version: 1.0
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 18:23:40 -0000
Yes, we have been using random values and have not got into any issues with clients/servers. -Xiaoyong From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Ryan Hurst Sent: Wednesday, September 11, 2013 9:19 AM To: Eric Rescorla Cc: perpass@ietf.org; tls@ietf.org; Alfredo Pironti Subject: Re: [TLS] Let's remove gmt_unix_time from TLS 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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
- [TLS] Let's remove gmt_unix_time from TLS Nick Mathewson
- Re: [TLS] Let's remove gmt_unix_time from TLS Alfredo Pironti
- Re: [TLS] Let's remove gmt_unix_time from TLS Russ Housley
- Re: [TLS] Let's remove gmt_unix_time from TLS Eric Rescorla
- Re: [TLS] Let's remove gmt_unix_time from TLS Adam Langley
- Re: [TLS] [perpass] Let's remove gmt_unix_time fr… Nick Mathewson
- Re: [TLS] Let's remove gmt_unix_time from TLS Ryan Hurst
- Re: [TLS] Let's remove gmt_unix_time from TLS Nick Mathewson
- Re: [TLS] Let's remove gmt_unix_time from TLS Paul Wouters
- Re: [TLS] Let's remove gmt_unix_time from TLS p.j.bakker
- Re: [TLS] Let's remove gmt_unix_time from TLS Hanno Böck
- Re: [TLS] Let's remove gmt_unix_time from TLS Nick Mathewson
- Re: [TLS] Let's remove gmt_unix_time from TLS Martin Rex
- Re: [TLS] Let's remove gmt_unix_time from TLS Xiaoyong Wu
- Re: [TLS] [perpass] Let's remove gmt_unix_time fr… Nick Mathewson
- Re: [TLS] [perpass] Let's remove gmt_unix_time fr… Martin Rex
- Re: [TLS] Let's remove gmt_unix_time from TLS Peter Gutmann
- Re: [TLS] Let's remove gmt_unix_time from TLS Marsh Ray
- Re: [TLS] [perpass] Let's remove gmt_unix_time fr… Stephen Farrell
- Re: [TLS] [perpass] Let's remove gmt_unix_time fr… Peter Gutmann
- Re: [TLS] Let's remove gmt_unix_time from TLS Wan-Teh Chang
- Re: [TLS] Let's remove gmt_unix_time from TLS Brian Smith
- Re: [TLS] Let's remove gmt_unix_time from TLS Stephen Farrell
- Re: [TLS] Let's remove gmt_unix_time from TLS Wan-Teh Chang
- Re: [TLS] Let's remove gmt_unix_time from TLS Nick Mathewson
- Re: [TLS] Let's remove gmt_unix_time from TLS Nick Mathewson
- Re: [TLS] Let's remove gmt_unix_time from TLS Martin Thomson
- Re: [TLS] Let's remove gmt_unix_time from TLS Martin Rex