IETF Logo Mail Archive

Re: [TLS] How to Validate Servers' Identities w/out reliable source of time

Peter Gutmann <pgut001@cs.auckland.ac.nz> Fri, 05 October 2018 01:00 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 62322130DBE for <tls@ietfa.amsl.com>; Thu, 4 Oct 2018 18:00:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 p_Ht6WWdM3gJ for <tls@ietfa.amsl.com>; Thu, 4 Oct 2018 18:00:08 -0700 (PDT)
Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 89EDD130DC3 for <tls@ietf.org>; Thu, 4 Oct 2018 18:00:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1538701207; x=1570237207; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=zONgmbBI/67wrJ9ev9EBsLQdHIXr694yWQDIKip0Iz8=; b=x5GCWnGftmcqtgrVWPbGCCUFG+cKarl2T6MHWSmo6O0RMDkT9oTNlmrA Gr4S0T1R6ukkXtUJZd7ziypwj+QQPmMS4GxK0KyKt5MfQQ+96+Ecnd74J WXpxczQ92wuZR7bcJqjQoaqo/G/odYA3EW0IvD44BNkYHCSA0PamVBG/Y +0+Ko94t135YZ/9eoRXGr4BshIYjsC+wddAp/ujj9sElzldiWR7Wi3Res AGoDNDMQwBwNH31bxNsMyrFCDVg2EhDLNLmRHKKpttj1d4qHJtKEiR1fx xqc0THU/o6Xyrxvv48FpUeS4mf5JRWx53zok96rhRXiXwhY9Ag0eMjFBV Q==;
X-IronPort-AV: E=Sophos;i="5.54,342,1534766400"; d="scan'208";a="33670698"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.8 - Outgoing - Outgoing
Received: from uxcn13-ogg-e.uoa.auckland.ac.nz ([10.6.2.8]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 05 Oct 2018 14:00:04 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.8) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 5 Oct 2018 14:00:04 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Fri, 5 Oct 2018 14:00:04 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "Dr. Pala" <director@openca.org>, TLS WG <tls@ietf.org>
Thread-Topic: [TLS] How to Validate Servers' Identities w/out reliable source of time
Thread-Index: AQHUW/Y9jpkjrxv0XkOq614twMG5P6UP1U2R
Date: Fri, 05 Oct 2018 01:00:04 +0000
Message-ID: <1538701198755.6342@cs.auckland.ac.nz>
References: <90b6138b-acf9-0836-79e8-556c81d1029a@openca.org>
In-Reply-To: <90b6138b-acf9-0836-79e8-556c81d1029a@openca.org>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/jIk_G6hsbiz6aZpvz7tILkgyLV8>
Subject: Re: [TLS] How to Validate Servers' Identities w/out reliable source of time
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 05 Oct 2018 01:00:11 -0000

Dr. Pala <director@openca.org> writes:

>In particular, the problem is that without a reliable (or trusted) source of
>Time information, devices can not reliably validate certificates (i.e., is
>the certificate even valid... ? is it expired ? is the revocation info fresh
>enough ?) and my question for the list is about best practices in the space.

It depends what your goal is.  Are you doing the validity checking because
some document says you need to, or because it's required for an actual
security goal?  You mention IoT, in a lot of embedded/SCADA there's little to
no checking done because the goal is as close to 100% uptime as achievable,
and shutting down because of an expired cert when everything else is operating
normally is a absolute no-no.

What security and non-security goals are you aiming for?

Peter.

v2.23.0 | Report a Bug | By Email