Re: [TLS] No more GMT exposure in the handshake

Bill Frantz <frantz@pwpconsult.com> Sun, 08 June 2014 22:52 UTC

Return-Path: <frantz@pwpconsult.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584A51A041D for <tls@ietfa.amsl.com>; Sun, 8 Jun 2014 15:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0am0IGudJKx for <tls@ietfa.amsl.com>; Sun, 8 Jun 2014 15:52:01 -0700 (PDT)
Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 379581AD62A for <tls@ietf.org>; Sun, 8 Jun 2014 15:51:57 -0700 (PDT)
Received: from [173.75.83.174] (helo=Williams-MacBook-Pro.local) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <frantz@pwpconsult.com>) id 1WtlwS-0008N5-V9; Sun, 08 Jun 2014 18:51:57 -0400
Date: Sun, 8 Jun 2014 15:51:56 -0700
From: Bill Frantz <frantz@pwpconsult.com>
To: Jacob Appelbaum <jacob@appelbaum.net>
X-Priority: 3
In-Reply-To: <CAFggDF3W1jV8wtnHq9wqOYS16ZMToG3cgi9jcUqQzL5Tpk_9+w@mail.gmail.com>
Message-ID: <r422Ps-1075i-B36419A9232F40C5B2900013D181D4AC@Williams-MacBook-Pro.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec794ff1a770b3ea9ee2301e26b17d11952f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 173.75.83.174
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Y2BF4i0b76Vz8WS4EGpm9kaAxC8
Cc: tls@ietf.org
Subject: Re: [TLS] No more GMT exposure in the handshake
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 08 Jun 2014 22:52:02 -0000

On 6/8/14 at 3:27 PM, jacob@appelbaum.net (Jacob Appelbaum) wrote:

>On 6/8/14, Bill Frantz <frantz@pwpconsult.com> wrote:
>>On 6/8/14 at 3:17 AM, kurt@roeckx.be (Kurt Roeckx) wrote:
>>
>>>Anyway, how do you plan to deal with checking the status of the
>>>certificate if you don't know what the current time is?
>>
>>It seems to be a poor policy to trust time information from a
>>server whose certificate you are trying to validate.
>
>Isn't it worse to trust a network protocol without any cryptographic
>assurances at all? I think so... I also tend to think the right choice
>is to fix NTP but we'll almost always have this first leap of
>something. I'd prefer it not to be a mere leap of faith but rather a
>leap of cryptographic assertion pinned to a set of keys that I trust.
>
>Until the time that NTP is fixed to deal with hostile networks, we've
>got hundreds of thousands of SSL/TLS servers on the internet that
>serve mostly accurate time.

OK, after making a flip remark, now I need to actually think 
about the requirements. For validating certificates (only):

   Time accuracy +- 24 hours or so.

   Trust in the time source.

If I get my time from the server I'm validating, then continued 
use of expired certificates is really easy. If I get it from a 
separate NTP server,then the attack becomes harder, but someone 
controlling my network traffic still has a relatively easy 
problem. If I use almost any source of time, and verify big 
jumps from my local clock with my user, the problem becomes 
almost impossibly difficult.

BTW, I have two devices, a radio and a Raspberry Pi, which have 
internal clocks which are reset to zero at power on. These would 
be vulnerable to the first two scenarios and not able to 
implement the third scenario. Its a good thing my plans for them 
don't involve network connections.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"Web security is like medicine - trying to 
do good for
408-356-8506       |an evolved body of kludges" - Mark Miller
www.pwpconsult.com |