Re: [TLS] Server time

Florian Weimer <fweimer@redhat.com> Tue, 07 April 2015 21:02 UTC

Return-Path: <fweimer@redhat.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 D40F11A0161 for <tls@ietfa.amsl.com>; Tue, 7 Apr 2015 14:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 9l1nBUYDCYGV for <tls@ietfa.amsl.com>; Tue, 7 Apr 2015 14:02:07 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1527D1B3C9E for <tls@ietf.org>; Tue, 7 Apr 2015 14:02:06 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t37L22xU030828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 7 Apr 2015 17:02:02 -0400
Received: from oldenburg.str.redhat.com ([10.10.116.43]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t37L1xsM023899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2015 17:02:01 -0400
Message-ID: <552445C4.4000800@redhat.com>
Date: Tue, 07 Apr 2015 23:01:56 +0200
From: Florian Weimer <fweimer@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, "<tls@ietf.org>" <tls@ietf.org>
References: <9A043F3CF02CD34C8E74AC1594475C73AAFDB9EC@uxcn10-tdc05.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFDB9EC@uxcn10-tdc05.UoA.auckland.ac.nz>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/akAuen9OEWv_NnU6ynHDsmY03UQ>
Subject: Re: [TLS] Server time
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: Tue, 07 Apr 2015 21:02:14 -0000

On 04/06/2015 02:45 PM, Peter Gutmann wrote:
> Tom Ritter <tom@ritter.vg> writes:
> 
>> Is it better or worse than relying on a completely unauthenticated protocol
>> to get the time?
> 
> If you really need a secure time source you either use NTPv4 security

NIST has published a protocol for NTPv4 key negotiation:

  <http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm>

Yes, it's a manual protocol, due to the lack of better alternatives.

> or run your own stratum 1.

That's still subject to spoofing.  One solution is to obtain
cryptographically secured time from the national time source (which
exists in most countries, I assume), with a baked-in (CA) certificate.
If it's wrong, it's still correct because it's the official time.

The Network Time Security effort more or less explicitly excludes
importing time from the outside (over the Internet or otherwise) because
it's requirements RFC, RFC 7384, explicitly states this is a
non-requirement in section 3.2.10.  (The RFC also has requirements which
seem quite impossible to implement.)

The current NTS protocol proposal uses CMS over UDP for key negotiation,
but has some issues.  I don't know yet if they can be persuaded to adopt
DTLS (maybe lack of server-side state is absolutely critical to them).

-- 
Florian Weimer / Red Hat Product Security