Re: [TLS] [perpass] Let's remove gmt_unix_time from TLS
Nick Mathewson <nickm@torproject.org> Thu, 12 September 2013 03:51 UTC
Return-Path: <nick.a.mathewson@gmail.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 4E65E21E8128; Wed, 11 Sep 2013 20:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.726
X-Spam-Level:
X-Spam-Status: No, score=-1.726 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 1j5P5BRAAzz2; Wed, 11 Sep 2013 20:51:30 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id BEB9021E8122; Wed, 11 Sep 2013 20:51:28 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id ep20so8078574lab.2 for <multiple recipients>; Wed, 11 Sep 2013 20:51:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=pFrMfEaZLUQ0i0pHlHuaRqSUvR8ShZy7SbRVYvG2CRg=; b=zgorwEkDUCdmi7O6aTdFrwMSfWoJ2NkNhgFjZZHR2WQXup1+97sHC6+qhLAVrlYr1I x5bIdNi/g1hX0sqPwMyxXydEZvYjOPQeBRya85aOxWLzGyZSIw2irBLQ1x5zwsarPr1Z WLRIpxlYol+cy54N/n2/yioKR174i9QVU+Jy0LBVlp6dYZJQg2qZ/8QZi2DEhC+Y9do0 BwBfIix0qGS0yn04oImX0SI1/IZKOFVgcUy6Ig7mMxcA2YAAqILiPh2wXPHcCz2mOxCK KE/zjqEcJVENtHlnFFw+2oIFUBwQETMpXXhqNz/ouxM8hZJGmi3JGfJDHzsc3gGsxzVd +fnA==
MIME-Version: 1.0
X-Received: by 10.112.126.37 with SMTP id mv5mr5549191lbb.20.1378957880839; Wed, 11 Sep 2013 20:51:20 -0700 (PDT)
Sender: nick.a.mathewson@gmail.com
Received: by 10.112.30.166 with HTTP; Wed, 11 Sep 2013 20:51:20 -0700 (PDT)
In-Reply-To: <20130911174135.455A01A960@ld9781.wdf.sap.corp>
References: <CAKDKvuw240Ug4xB3zi2w0y7pUvCwSe0nNFZ2XP2vL-tbtKT0tg@mail.gmail.com> <20130911174135.455A01A960@ld9781.wdf.sap.corp>
Date: Wed, 11 Sep 2013 23:51:20 -0400
X-Google-Sender-Auth: qrYdXjCpbpbr9boikU2391fFQu0
Message-ID: <CAKDKvuy9QRT9Q500K1o8wHg-5s0hCx88_A_TSm8f6tOky6R4iw@mail.gmail.com>
From: Nick Mathewson <nickm@torproject.org>
To: mrex@sap.com
Content-Type: text/plain; charset="ISO-8859-1"
Cc: perpass@ietf.org, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] [perpass] 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: Thu, 12 Sep 2013 03:51:32 -0000
On Wed, Sep 11, 2013 at 1:41 PM, Martin Rex <mrex@sap.com> wrote: > Nick Mathewson wrote: >> ==== >> 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. > > 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. > 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. This is not such a fundamental transformation. This is a little simple change to fix a little simple little problem. 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. 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.) -- Nick
- [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