IETF Logo Mail Archive

Re: [TLS] Server time

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 07 April 2015 23:13 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 DAB041A8035 for <tls@ietfa.amsl.com>; Tue, 7 Apr 2015 16:13:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level:
X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 XbBFfeBjD4kR for <tls@ietfa.amsl.com>; Tue, 7 Apr 2015 16:13:13 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE8F1A7014 for <tls@ietf.org>; Tue, 7 Apr 2015 16:13:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1428448394; x=1459984394; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=k2EVbggb+hEmvlCkpIBrwQUTWBZtSBkR4FFWwW/F78c=; b=bc6wHlHYLT5Jgm9WF5ZiCocIXxrG9LoHikeJhwdPdoNAk99Oq9nwAdnE 4dHZq7tStS8jOpOaIDHHkhYUIfrzIDIM8Yx7VrntBQCUZbs/Ht/nMIFrI sbl2ALcdEsNgLfUj4E5xb31+HZ9bk/K2j8XFKFt40t4YcN+n/aGHgn4MR 0=;
X-IronPort-AV: E=Sophos;i="5.11,540,1422874800"; d="scan'208";a="319347125"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 08 Apr 2015 11:13:12 +1200
Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.245]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Wed, 8 Apr 2015 11:13:10 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Florian Weimer <fweimer@redhat.com>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Server time
Thread-Index: AdBwZ6GD+C5DBwD+SeCkDTaZlcyh5AAqd3oAAB23Emk=
Date: Tue, 07 Apr 2015 23:13:10 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AAFDD546@uxcn10-tdc05.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C73AAFDB9EC@uxcn10-tdc05.UoA.auckland.ac.nz>, <552445C4.4000800@redhat.com>
In-Reply-To: <552445C4.4000800@redhat.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/49uJy5cNn4OUU93r7GABsGQsSVY>
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 23:13:17 -0000

Florian Weimer <fweimer@redhat.com> writes:
>On 04/06/2015 02:45 PM, Peter Gutmann wrote:
>> or run your own stratum 1.
>
>That's still subject to spoofing.

If you're up against an attacker who's got the ability, means, and motivation
to haul sophisticated GPS-spoofing equipment to wherever you are and deploy it
against you, presumably in some manner where it won't interfere with other GPS
activity which would make it detectable, then you're toast anyway.

In the situations I know of where time is part of the TCB, the other side
tracks the source's clock drift and compensates accordingly.  In other words
the source has some built-in clock that doesn't have to be very accurate, as
long as it's reasonably consistently inaccurate, i.e. not a Vetinari clock.

Peter.

v2.23.0 | Report a Bug | By Email