Subject: Re: [TLS] Server time

From: Peter Gutmann <[email-masked]>
Date: Mon, 6 Apr 2015 11:15:44 +0000

Dave Garrett <[email-masked]> writes:

>adding a 4 byte uint32 ServerHello.time for TLS 1.3+ seems like a really
>simple solution. (note that ServerHello is already changed by dropping
>compression_method)

It's also a really dangerous solution.  All of PKI is critically dependent on
everyone having the correct time.  For a server to advertise the fact that its
clock is off, and thus revoked and expired certs will still be regarded as
valid (among other things) is a really bad idea.

>The ability of a client to sanity check or sync its time seems like something
>worth having, especially for only a 4 byte cost.

Given that there's already a globally-deployed dedicated infrastructure that
requires nothing more complicated than sending a single UDP packet to port 123
and checking the response, turning your TLS server into a sort of proxy time
server that may or may not have the correct time in the first place seems like
a bad idea.

Peter.

---

From: Tom Ritter <[email-masked]>
Date: Mon, 6 Apr 2015 06:34:53 -0500

> server that may or may not have the correct time in the first place seems like

Is it better or worse than relying on a completely unauthenticated
protocol to get the time?

AGL commented earlier on this topic that ChromeOS uses (a fork of?)
tlsdate to set the time securely, and that Google will likely keep
some (all?) servers responding with a valid time to support that use
case. I don't know what other users of tlsdate (Whonix, etc) point to.

I think we can do away with server time in TLS 1.3, and the future
solution is TLS 1.2 to a known-good server (or HTTPS for the Date
Header) for rough time accuracy and NTP for correcting the skew.

-tom

---

From: Kurt Roeckx <[email-masked]>
Date: Mon, 6 Apr 2015 13:44:36 +0200

> server that may or may not have the correct time in the first place seems like

There is work being done to make NTP more secure.  But if you
don't know what time it is there is no way that we know how to
get the correct time in a secure way.  About the best you can do
is assume that not everybody is compromised.

Kurt

---

From: Florian Weimer <[email-masked]>
Date: Wed, 08 Apr 2015 10:11:50 +0200

> is assume that not everybody is compromised.

What about hard-coded (CA) certificates?

The time dependency was pioneered by X.509/PKIX and its certificate
revocation model, it's not inherent to (asymmetric) cryptography.

-- 
Florian Weimer / Red Hat Product Security

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 8 Apr 2015 12:15:29 +0200

> What about hard-coded (CA) certificates?

That might have expired, been revoked, whatever.  If you go and
check a CRL the attacker might give you an old copy.  If you use
OCSP it might give you an old reply.  You probably at least want
an OCSP server that supports a nonce.

Kurt

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 8 Apr 2015 06:27:27 -0400

> an OCSP server that supports a nonce.
Gossip protocols.

As the density of networked devices increases (especially with mobile
clients), I think it makes sense to look at it as a partial solution
or a way to reduce the problem. The mobile clients bring in time from
outside channels, so its a nice cross check.

A device still probably needs to contact an NTP server on occasion for
sanity checking. But there won't be a need to hammer a secure time
server every 30 minutes or every hour.