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

mrex@sap.com (Martin Rex) Thu, 12 September 2013 04:17 UTC

Return-Path: <mrex@sap.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 7C16421F9C06; Wed, 11 Sep 2013 21:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 13sas5iH2Gqx; Wed, 11 Sep 2013 21:17:36 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC7521F9E99; Wed, 11 Sep 2013 21:17:35 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r8C4HXJi025819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Sep 2013 06:17:33 +0200 (MEST)
In-Reply-To: <CAKDKvuy9QRT9Q500K1o8wHg-5s0hCx88_A_TSm8f6tOky6R4iw@mail.gmail.com>
To: Nick Mathewson <nickm@torproject.org>
Date: Thu, 12 Sep 2013 06:17:33 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20130912041733.817521A961@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
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
Reply-To: mrex@sap.com
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 04:17:40 -0000

Nick Mathewson wrote:
> 
> 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.

Huh?  where in rfc6101, rfc2246, rfc4346 or rfc5246 do you find
_anything_at_all_ that could be remotely interpreted as a
requirement for ClientHello.Random.gmt_unix_time to have any
specific value or be within any particular value range -- 
in contradiction to what section 7.4.1.2 says?

(Same for ServerHello.Random.gmt_unix_time).

   http://tools.ietf.org/html/rfc2246#section-7.4.1.2

       Structure of this message:
           The client hello message includes a random structure, which is
           used later in the protocol.

           struct {
              uint32 gmt_unix_time;
              opaque random_bytes[28];
           } Random;

       gmt_unix_time
       The current time and date in standard UNIX 32-bit format (seconds
       since the midnight starting Jan 1, 1970, GMT) according to the
       sender's internal clock. Clocks are not required to be set
       correctly by the basic TLS Protocol; higher level or application
       protocols may define additional requirements.


Which part of "Clocks are not required to be set correctly by the
basic TLS protocol" is unclear?  This explicitly spells out that
one can send _ANY_ pattern of 32 bits as gmt_unix_time, as far as
the SSLv3&TLS protocol specifications themselves are concerned.


-Martin