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

From: "Dr. Pala" <[email-masked]>
Date: Thu, 4 Oct 2018 09:22:55 -0600

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 ?

Cheers,
Max

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

---

From: Rob Stradling <[email-masked]>
Date: Thu, 4 Oct 2018 17:57:07 +0100

Hi Max.  The most promising solution I've seen to this problem is 
Google's Roughtime protocol.

Adam Langley's blog post:
https://www.imperialviolet.org/2016/09/19/roughtime.html

Protocol description:
https://roughtime.googlesource.com/roughtime/+/HEAD/PROTOCOL.md

Open-source implementation:
https://roughtime.googlesource.com/roughtime

Cloudflare's Roughtime service:
https://blog.cloudflare.com/roughtime/

-- 
Rob Stradling
Senior Research & Development Scientist
Email: [email-masked]

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 5 Oct 2018 01:00:04 +0000

Dr. Pala <[email-masked]> 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.