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
- [TLS] Server time Dave Garrett
- Re: [TLS] Server time Erik Nygren
- Re: [TLS] Server time Jeffrey Walton
- Re: [TLS] Server time Dave Garrett
- Re: [TLS] Server time Dave Garrett
- Re: [TLS] Server time Jeffrey Walton
- Re: [TLS] Server time Hauke Mehrtens
- Re: [TLS] Server time Brian Smith
- Re: [TLS] Server time Jeffrey Walton
- Re: [TLS] Server time Eric Rescorla
- Re: [TLS] Server time Dave Garrett
- Re: [TLS] Server time Peter Gutmann
- Re: [TLS] Server time Tom Ritter
- Re: [TLS] Server time Kurt Roeckx
- Re: [TLS] Server time Peter Gutmann
- Re: [TLS] Server time Martin Thomson
- Re: [TLS] Server time Jeffrey Walton
- Re: [TLS] Server time Adam Caudill
- Re: [TLS] Server time Jeffrey Walton
- Re: [TLS] Server time Ben Laurie
- Re: [TLS] Server time Florian Weimer
- Re: [TLS] Server time Peter Gutmann
- Re: [TLS] Server time Florian Weimer
- Re: [TLS] Server time Kurt Roeckx
- Re: [TLS] Server time Florian Weimer
- Re: [TLS] Server time Kurt Roeckx
- Re: [TLS] Server time Jeffrey Walton