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

From: Watson Ladd <[email-masked]>
Date: Sun, 2 Nov 2014 13:56:09 -0800

Dear all,
NTP needs to be secure, ergo we have NTP Autokey. Problem solved? Of
course not, otherwise I wouldn't be writing this email.

Most NTP servers and clients can't use autokey. Many servers are run
as part of pools, making it difficult to secure NTP effectively with
autokey because of a mismatch in trust models. Most clients can't use
autokey, because autokey fails in the presence of NATs. Many client
implementations don't want to embed reams of code from OpenSSL, and
RFC 5906 defines several important data structures in terms of this
code, as well as relying on X509.

Many of the choices in Autokey were designed to help attain
microsecond precision. However most users of secure NTP don't need
that level of precision: they want to get an authentic time within
minutes, not an inauthentic time to within microseconds, and they want
to do it with pools and from behind NATs.

As usual this was known when the standard was being written. We have a
hard enough time deploying crypto that works: it's even worse when the
only solution to a problem is DOA, because it solves the wrong
problem.

The impact of insecure time is hard to understate. Every single
expiration time, be it on zone keys in DNSSEC, OCSP stapling
responses, X509 certificates, or even DNS responses, can be evaded by
an attacker who manipulates the network by faking NTP packets at boot
time. On most (all?) operating systems this is sufficient to change
the clock to whatever time is desired, and thus evade all the checks
depending on synchronized clocks.

Luckily the NTP working group is considering drafts that address some
of these issues. However, it still is not addressing pool security.
I'm at my limit of effective participation, but I hope that this
problem is solved sooner, rather than later. Without secure time, a
lot of security mechanisms do not work. In the course of writing this
email, I discovered that this is on the SAAG agenda for Hawaii, and I
hope that these issues get raised in that discussion.

I also hope that in Hawaii SAAG carefully examine the role of IETF
working groups in promoting security, the lack of effective
depreciation of old protocols, the relations between implementors,
standards bodies, and administrators, and how we are going to get to a
world in which every packet is encrypted with security protocols that
work. I don't think that the current agenda or drafts advance this
goal.

Sincerely,
Watson Ladd

---

From: Tony Finch <[email-masked]>
Date: Mon, 3 Nov 2014 11:13:44 +0000

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

I have a proposal for DNSSEC root trust anchor bootstrap and rollover
based on similar ideas:

http://tools.ietf.org/html/draft-fanf-dnsop-trust-anchor-witnesses

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 3 Nov 2014 10:42:01 -0500

Hello,

Thanks for sharing your thoughts.

> hope that these issues get raised in that discussion.

We will have open mic time after the talks that are planned and can
see what develops, then bring it to the appropriate lists for
discussion.  If there are additional drafts needed, getting volunteers
would be good.  Let's see how the discussion goes in Hawaii and thanks
for raising these points.
> work. I don't think that the current agenda or drafts advance this

We've started a little bit of discussion on this topic between a few
of the ADs, but have not taken it far enough yet.  It's a bit tricky
to figure out what the right approach will be and more discussion is
needed.  I'll see if there is time to add this on the agenda, but
would encourage more suggestions to be discussed on the SAAG list in
the meantime.  I don't like the idea of waiting for something to break
before fixing it as what happened with POODLE.  It's also hard to get
everyone to make the switch or enough to have the impact.  This
particular topic does require more consideration and I think anything
we do would need to be coupled with marketing (even twitter in a
positive way - praising those who have made updates) to motivate
change.

Thanks,
Kathleen

>
> Sincerely,
> Watson Ladd
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

-- 

Best regards,
Kathleen

---

From: Nico Williams <[email-masked]>
Date: Mon, 3 Nov 2014 10:14:44 -0600

> http://tools.ietf.org/html/draft-fanf-dnsop-trust-anchor-witnesses

+1

This is, in my mind, related to gossip protocols, which DNSSEC does
need.

(Can witnesses gang up on the zone (here the root) they witness for to
DoS it?  But of course that's unlikely; still, it should be mentioned in
the Security Considerations.)

Nico
--

---

From: Tony Finch <[email-masked]>
Date: Mon, 3 Nov 2014 16:49:15 +0000

> the Security Considerations.)

Yes in all respects.

The really tricky aspect of this idea is being sure that you are talking
to several *different* sources of information. If they share some common
infrastructure then it is likely that you are trusting that infrastructure
more than you intended to. (There's more discussion about this in my
second post on Temporum http://fanf.livejournal.com/129371.html)

My current thinking is that this is easiest to deal with if you have a
carefully chosen statically configured list of witnesses, aiming for
quality rather than quantity. But perhaps gossip protocols are a better
(more widely applicable) way to solve the problem.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher: Southerly or southwesterly 5 to 7, occasionally gale 8 in east,
veering westerly 4 or 5. Moderate or rough, becoming slight or moderate later.
Rain or squally showers. Good, occasionally moderate.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 3 Nov 2014 11:59:48 -0500

> positive way - praising those who have made updates) to motivate

I should have mentioned phasing out SSL 3 here as the example.  Some
of the difficulties we'll have to consider in how the IETF can
influence change and phasing out older protocols, algorithms, etc. is
the way vulnerability disclosure is handled between companies.  For
good reason, it is a very private process between those effected with
strict disclosure rules prior to any announcements.  Often, vendors
will want to be ready with the actions they plan to take prior to
announcements to mitigate the effect (ability to exploit) the
vulnerability could have once announced.

-- 

Best regards,
Kathleen

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Nov 2014 18:32:46 -0600

If NTP WG is concluded, it should be marked as such.  It's not, but it
looks very stale.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 11 Nov 2014 19:40:35 -0600

Oh, har, it's been pointed out that NTP WG does meet this week.
Apologies for the noise.