Subject: Re: [saag] NTP security, and thoughts on Hawaii

From: Peter Gutmann <[email-masked]>
Date: Mon, 3 Nov 2014 17:42:48 +0000

Tony Finch <[email-masked]> writes:

>I did some experiments last year on secure time, based on the principle of
>getting the time from multiple marginally-trusted third parties and
>determining what time they agree on. I have not been following the NTP WG.
>
>http://fanf.livejournal.com/128861.html
>http://fanf.livejournal.com/129371.html

tlsdate is quite risky because it relies on a feature that some servers
already don't support (telling a potentially hostile client what your idea of
the current time is isn't a good idea) and that definitely won't be present in
TLS 1.3.

If you're really worried about the validity of your time, why not hook a GPS
to a Raspberry Pi and run that as an NTP server, or get a prebuilt one like
this:

https://www.tindie.com/products/gxti/laureline-gps-ntp-server/

That can still be spoofed, but getting in close proximity to where you're
running the server and spoofing GPS signals is a lot trickier than spoofing
NTP over a network.

Peter.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 03 Nov 2014 09:47:53 -0800

Hi Peter,

I won't comment on the rest of this, but...

> running the server and spoofing GPS signals is a lot trickier than spoofing

In particular it requires access to the sky, which in any number of
cases is not possible.  Perhaps that's beyond the general case, but
worth thinking about.

Eliot

---

From: Nico Williams <[email-masked]>
Date: Mon, 3 Nov 2014 11:53:20 -0600

Mobile devices typically have a GPS receiver too...

Still, it'd be nice to have a secure NTP that scales.  Do we have an
analysis of NTP autokey?  What's wrong with it?  Is it just a matter
of lack of deployment?

(I imagine that signing every NTP multicast could be problematic, but
what about including a signature of the previous multicast in every
new one?)

Nico
--

---

From: Tony Finch <[email-masked]>
Date: Tue, 4 Nov 2014 09:38:53 +0000

> the current time is isn't a good idea) and that definitely won't be present in

Sort of: it can alternatively use the HTTP Date: header. I prefer to get
the time from servers that are provisioned for that purpose rather than
doing it parasitically, but tlsdate was useful for an experimental proof
of concept.

> to a Raspberry Pi and run that as an NTP server, or get a prebuilt one like

The point is not to help experts get the time securely in a managed
environment: NTPsec already suffices. My aim is something that can
bootstrap time securely on a consumer device without a battery backed
clock or user interface more complicated than a few LEDs.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher, Northwest German Bight: Westerly 4 or 5, occasionally 6 in north
Fisher, becoming variable 3 or 4 later. Slight or moderate, becoming moderate
or rough later. Showers. Good, occasionally moderate.

---

From: Tony Finch <[email-masked]>
Date: Tue, 4 Nov 2014 09:42:14 +0000

Nico Williams <[email-masked]> wrote:
> analysis of NTP autokey?  What's wrong with it?

It is crippled by NAT, because the peer IP addresses are part of the
authentication key. Also, I could not work out how to configure it to
support the usual anonymous client / authenticated server setup that you
would need for something like the NTP pool.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Portland: Northwest 5 or 6. Moderate or rough. Thundery showers. Good,
occasionally moderate.