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

Marsh Ray <maray@microsoft.com> Thu, 12 September 2013 08:26 UTC

Return-Path: <maray@microsoft.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 6B5D221E8160; Thu, 12 Sep 2013 01:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 nzMYVfRRUy63; Thu, 12 Sep 2013 01:25:55 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 32B1121E8154; Thu, 12 Sep 2013 01:25:54 -0700 (PDT)
Received: from BLUPR03MB166.namprd03.prod.outlook.com (10.255.212.142) by BLUPR03MB167.namprd03.prod.outlook.com (10.255.212.143) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 12 Sep 2013 08:25:49 +0000
Received: from BLUPR03MB166.namprd03.prod.outlook.com ([169.254.4.249]) by BLUPR03MB166.namprd03.prod.outlook.com ([169.254.4.249]) with mapi id 15.00.0775.005; Thu, 12 Sep 2013 08:25:49 +0000
From: Marsh Ray <maray@microsoft.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Eric Rescorla <ekr@rtfm.com>, Alfredo Pironti <alfredo@pironti.eu>, "perpass@ietf.org" <perpass@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Let's remove gmt_unix_time from TLS
Thread-Index: Ac6vd9PFx71XQUH1RkGmUyB65MA//gAGLggg
Date: Thu, 12 Sep 2013 08:25:48 +0000
Message-ID: <ad4ca8b6ef3a4d8b8c7220de3ee9bd2b@BLUPR03MB166.namprd03.prod.outlook.com>
References: <9A043F3CF02CD34C8E74AC1594475C735566D793@uxcn10-tdc06.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735566D793@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:ed31::3]
x-forefront-prvs: 0967749BC1
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(74316001)(74366001)(74876001)(19580405001)(19580395003)(83322001)(83072001)(81342001)(81542001)(80976001)(76482001)(81816001)(81686001)(65816001)(79102001)(54316002)(76576001)(76786001)(74502001)(56816003)(77096001)(56776001)(76796001)(31966008)(69226001)(74706001)(49866001)(4396001)(50986001)(47976001)(47736001)(53806001)(54356001)(63696002)(59766001)(77982001)(46102001)(80022001)(47446002)(33646001)(51856001)(74662001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB167; H:BLUPR03MB166.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::3; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com
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: Thu, 12 Sep 2013 08:26:00 -0000

> Eric Rescorla <ekr@rtfm.com> writes:
>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?

I just checked and the current version doesn't do this, but ISTR older Internet Explorer would populate the "GMT" field with the local time. If my recollection is true, this would probably represent "broad scale".

This would reveal the client's time zone. So particularly for clients traversing VPNs and proxies it would represent an info leak to a passive eavesdropper positioned near the server.

- Marsh