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

"Dr. Pala" <director@openca.org> Thu, 04 October 2018 15:22 UTC

Return-Path: <director@openca.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 74CC7130E61 for <tls@ietfa.amsl.com>; Thu, 4 Oct 2018 08:22:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.344
X-Spam-Status: No, score=-0.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hwzfEtffA5J0 for <tls@ietfa.amsl.com>; Thu, 4 Oct 2018 08:22:58 -0700 (PDT)
Received: from mail.katezarealty.com (mail.katezarealty.com []) by ietfa.amsl.com (Postfix) with ESMTP id E752D130E5E for <tls@ietf.org>; Thu, 4 Oct 2018 08:22:57 -0700 (PDT)
Received: from localhost (unknown []) by mail.katezarealty.com (Postfix) with ESMTP id 6B06F3740F88 for <tls@ietf.org>; Thu, 4 Oct 2018 15:22:57 +0000 (UTC)
X-Virus-Scanned: amavisd-new at katezarealty.com
Received: from mail.katezarealty.com ([]) by localhost (mail.katezarealty.com []) (amavisd-new, port 10024) with LMTP id QMAYePZZj_Ij for <tls@ietf.org>; Thu, 4 Oct 2018 11:22:56 -0400 (EDT)
Received: from Maxs-MBP.cablelabs.com (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 66AED37402AF for <tls@ietf.org>; Thu, 4 Oct 2018 11:22:56 -0400 (EDT)
To: TLS WG <tls@ietf.org>
From: "Dr. Pala" <director@openca.org>
Organization: OpenCA Labs
Message-ID: <90b6138b-acf9-0836-79e8-556c81d1029a@openca.org>
Date: Thu, 4 Oct 2018 09:22:55 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070001060004000500000706"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/FgYYgV81a3xWBHXwhNkhvr3e3qA>
Subject: [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: Thu, 04 Oct 2018 15:23:00 -0000

Hi all,

I am struggling with one issue that we have been seeing more and more 
often with the introduction of small IoT devices that connect to clouds 
via TLS and need to validate the cloud server's (or the other party's) 
certificate chain.

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. The problem is even more problematic 
for devices with limited access to the network (e.g., access only to 
specific servers / cloud services) since no "external" source of time 
can be used.

Do you know if there are indications / best practices from ITU or from 
IETF (or other organizations) on how to deal with this issue ? Has the 
issue been addressed somewhere ?


Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo