Subject: Re: [TLS] Server time

From: Peter Gutmann <[email-masked]>
Date: Mon, 6 Apr 2015 12:45:58 +0000

Tom Ritter <[email-masked]> writes:

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

If you really need a secure time source you either use NTPv4 security or run
your own stratum 1.  The problem with getting time from the server is, as
others and I have pointed out, the server may not have the correct time (or
any time at all for an embedded device), by manipulating the time the client
sees a malicious server can break the client's PKI, and so on.

Using TLS as a pseudo-NTP source makes about as much sense as using HTTP as a
pseudo-NTP source, which has happened a number of times in the past.  TLS is a
means of building a secure tunnel from A to B, not a kludgy way of avoiding
use of NTP.

Peter.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 6 Apr 2015 09:13:58 -0700

> means of building a secure tunnel from A to B, not a kludgy way of avoiding

Yes, this is right.  There's nothing inherently wrong with using a
HTTP server that you trust to have good time for a little sanity
checking.  That said, it doesn't make any sense to use arbitrary
servers.

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 6 Apr 2015 12:30:58 -0400

> checking.  That said, it doesn't make any sense to use arbitrary
+1. That was the exact use case I was envisioning - an LG refrigerator
abandons the browser security model and pins to LG's CA. In this case,
it trusts its own organization's PKI and servers (but no others).

Jeff

---

From: Adam Caudill <[email-masked]>
Date: Mon, 6 Apr 2015 19:19:58 -0400

> it trusts its own organization's PKI and servers (but no others).
In certain circumstances, using a HTTPS server as a time source isn't a
horrible idea, but why change TLS for such an edge case? To me, this seems
like a clear case of trying to address the issue at the wrong level - this
adds no security, introduces privacy issues, and introduces further changes
for an edge case that could easily be addressed in many other ways.

If there are use cases where it is important that time be acquired from an
HTTPS, have the server return the timestamp at whatever precision desired
as the body of the response to the GET request - it's still simple to work
with, and doesn't impact all TLS users as this would.

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 6 Apr 2015 19:49:39 -0400

> horrible idea, but why change TLS for such an edge case?
Well, that edge case is going to inundate us in years to come.

There will be hundreds  of millions of PC sales in a year; hundreds of
millions to billions of smartphones sales in a year, and billions of
IoT gadget sales in a year. Not to mention all the SmartCard
applications that may need it.

Is SSL_VERIFY_NONE really the only choice for resource constrained and
low end devices?

> HTTPS, have the server return the timestamp at whatever precision desired as
> the body of the response to the GET request - it's still simple to work
Doesn't that set-up the chicken-and-the-egg problem? Channel setup
will never occur because of the failed certificate validation due to
the time skew at the client.

Or maybe it won't matter because the folks programming the system will
helpfully add SSL_VERIFY_NONE.

Anyway, I'm not arguing either way. I just know what I've experienced
in the past, and I expect it to happen again in the future.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 7 Apr 2015 21:21:46 +0100

On 6 April 2015 at 13:45, Peter Gutmann <[email-masked]> wrote:
> your own stratum 1.

How does NTPv4 security provide a secure time source (i.e. something I
can rely on as if it were stratum 1)?

---

From: Florian Weimer <[email-masked]>
Date: Tue, 07 Apr 2015 23:01:56 +0200

On 04/06/2015 02:45 PM, Peter Gutmann wrote:
> If you really need a secure time source you either use NTPv4 security

NIST has published a protocol for NTPv4 key negotiation:

  <http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm>

Yes, it's a manual protocol, due to the lack of better alternatives.

> or run your own stratum 1.

That's still subject to spoofing.  One solution is to obtain
cryptographically secured time from the national time source (which
exists in most countries, I assume), with a baked-in (CA) certificate.
If it's wrong, it's still correct because it's the official time.

The Network Time Security effort more or less explicitly excludes
importing time from the outside (over the Internet or otherwise) because
it's requirements RFC, RFC 7384, explicitly states this is a
non-requirement in section 3.2.10.  (The RFC also has requirements which
seem quite impossible to implement.)

The current NTS protocol proposal uses CMS over UDP for key negotiation,
but has some issues.  I don't know yet if they can be persuaded to adopt
DTLS (maybe lack of server-side state is absolutely critical to them).

-- 
Florian Weimer / Red Hat Product Security

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 7 Apr 2015 23:13:10 +0000

Florian Weimer <[email-masked]> writes:
>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.

---

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

On Tue, Apr 07, 2015 at 11:01:56PM +0200, Florian Weimer wrote:
> I don't know yet if they can be persuaded to adopt

The lack of server-side state really is important to them.  There
are too many clients to keep track of.  I also think they want to
avoid having the crypto reduce the accuracy too much.  But I think
both problems can be solved.

Kurt

---

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

On 04/08/2015 12:06 PM, Kurt Roeckx wrote:
> are too many clients to keep track of.

DTLS would only be used to negotiate a shared key for subsequent message
authentication.  The DTLS sessions would not be persistent during an
entire NTP association.  If that's not clear from my comments, I should
send a clarification to the NTPWG list.

(UDP with large messages still needs state in the IP stack for fragment
reassembly, so even the current CMS-based proposal is not exactly
stateless.)