Subject: [Ntp] Spencer Dawkins' Yes on draft-ietf-ntp-bcp-10: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Mon, 17 Dec 2018 17:01:03 -0800

Spencer Dawkins has entered the following ballot position for
draft-ietf-ntp-bcp-10: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ntp-bcp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I understand every sentence in this text

  Many network security mechanisms rely on time as part of their
   operation.  If attackers can spoof the time, they may be able to
   bypass or neutralize other security elements.  For example, incorrect
   time can disrupt the ability to reconcile logfile entries on the
   affected system with events on other systems.  An application which
   is secure today could be insecure tomorrow once an unknown bug (or a
   known behavior) is exploited in the right way.  Even our definition
   of what is secure has evolved over the years, so code which was
   considered secure when it was written may turn out to be insecure
   after some time.

but don't understand how

   An application which
   is secure today could be insecure tomorrow once an unknown bug (or a
   known behavior) is exploited in the right way.  Even our definition
   of what is secure has evolved over the years, so code which was
   considered secure when it was written may turn out to be insecure
   after some time.

relates to an attack on NTP-provided time. Could you help me understand how
this is tied together?

Is "users" the right term in

3.6.  Using Pool Servers

   It only takes a small amount of bandwidth and system resources to
   synchronize one NTP client, but NTP servers that can service tens of
   thousands of clients take more resources to run.  Users who want to
   synchronize their computers SHOULD only synchronize to servers that
   they have permission to use.

? If I'm a user, I'm not thinking I've ever consciously chosen an NTP server.

You might consider moving that paragraph lower in 3.6 - the section is about
using pool servers, but the explanation about pool servers is in the second
paragraph.

Is the choice of lower case "should" in

3.7.1.  Leap Smearing

   Some NTP installations make use of a technique called Leap Smearing.
   With this method, instead of introducing an extra second (or
   eliminating a second) on a leap second event, NTP time will be slewed
   in small increments over a comparably large window of time (called
   the smear interval) around the leap second event.  The smear interval
   should be large enough to make the rate that the time is slewed
   small,

intentional? It seemed close enough to some of the SHOULDs in this document
that I wanted to ask ...

Is it obvious how a system administrator would detect a mixture of smeared and
non-smeared servers, as in

  System Administrators are advised to be aware of impending leap
   seconds and how the servers (inside and outside their organization)
   they are using deal with them.  Individual clients MUST NOT be
   configured to use a mixture of smeared and non-smeared servers.  If a
   client uses smeared servers, the servers it uses must all have the
   same leap smear configuration.

? I'm asking for the case where you carefully choose your servers so they
aren't mixed, but you are using servers you don't control, and the server
administrator changes the server behavior.

I don't think

  Operators SHOULD be aware that when operating with the above two
   conditions, the panic threshold offers no protection from attacks.

needs BCP14 requirements language. When would operators make an informed
decision to be unaware?

In this text,

  In addition, implementations SHOULD prevent the NTP daemon from
   taking time steps that set the clock to a time earlier than the
   compile date of the NTP daemon.

it would be helpful to me, to explain why this requirement is included. I can
imagine a couple of reasons, but I'm guessing.

I wonder if the SUIT working group has any drafts that are stable enough to be
used as an informative reference in Section 6.1, "Updating Embedded Devices".

---

From: Denis Reilly <[email-masked]>
Date: Wed, 19 Dec 2018 20:32:30 +0000

Thank you for your review, Spencer! Responses are in-line.

Best Regards,

--
Denis Reilly  |  Technical Lead  |  [email-masked]  (585)321-5837

-----Original Message-----
From: Spencer Dawkins <[email-masked]> 
Sent: Monday, December 17, 2018 8:01 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; Karen O'Donoghue <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Spencer Dawkins' Yes on draft-ietf-ntp-bcp-10: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

but don't understand how

   An application which

relates to an attack on NTP-provided time. Could you help me understand how this is tied together?

--DPR: the original intent was to highlight the importance of updating applications in general. But after some wordsmithing in the last few revisions, we now feel that the first part of the paragraph stands on its own and will omit the second part.

3.6.  Using Pool Servers

You might consider moving that paragraph lower in 3.6 - the section is about using pool servers, but the explanation about pool servers is in the second paragraph.

--DPR: We will clarify that “Network operators and advanced users who want to synchronize the computers on their networks” really need to pay attention.

3.7.1.  Leap Smearing

intentional? It seemed close enough to some of the SHOULDs in this document that I wanted to ask ...

--DPR: Yes, it’s intentional. Leap smearing is a bit controversial, and the only guidance we wanted to offer is when it should not be used.

Is it obvious how a system administrator would detect a mixture of smeared and non-smeared servers, as in

? I'm asking for the case where you carefully choose your servers so they aren't mixed, but you are using servers you don't control, and the server administrator changes the server behavior.

--DPR: We struggled with this a bit, as there’s no standard way to detect a leap smear. There is some work being done on this, but nothing is far enough along to make a formal recommendation. We recommend not to use leap smear on public facing servers, but we know that people do it anyway. We are taking the point of view that if we inform operators that this may happen, they can ask the questions they need to ask ahead of time (or have a better clue what might be going on if one of their upstream servers disagrees with the others over the leap second.)

I don't think

needs BCP14 requirements language. When would operators make an informed decision to be unaware?

--DPR: We agree, we'll change this.

In this text,

it would be helpful to me, to explain why this requirement is included. I can imagine a couple of reasons, but I'm guessing.

--DPR: We included it as a simple check against setting the time way too early that probably shouldn’t impact users

I wonder if the SUIT working group has any drafts that are stable enough to be used as an informative reference in Section 6.1, "Updating Embedded Devices".
--DPR: I don’t think anything there looks stable right now, but that looks like a good group to follow. Thanks for the tip!

ATTENTION: This email came from an external source.
Do not open attachments or click on links from unknown senders or unexpected emails.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 19 Dec 2018 16:29:53 -0600

Hi, Denis,

This is mostly fine. I have one follow-up (flagged as --SD).

On Wed, Dec 19, 2018 at 2:32 PM Denis Reilly <[email-masked]>
wrote:

> Cc: [email-masked]; Karen O'Donoghue <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]
> --DPR: the original intent was to highlight the importance of updating
> applications in general. But after some wordsmithing in the last few
> revisions, we now feel that the first part of the paragraph stands on its
> own and will omit the second part.
>
>
> You might consider moving that paragraph lower in 3.6 - the section is
> about using pool servers, but the explanation about pool servers is in the
> second paragraph.
>
> --DPR: We will clarify that “Network operators and advanced users who want
> to synchronize the computers on their networks” really need to pay
> attention.
>
> --DPR: Yes, it’s intentional. Leap smearing is a bit controversial, and
> the only guidance we wanted to offer is when it should not be used.
>
> --DPR: We struggled with this a bit, as there’s no standard way to detect
> a leap smear. There is some work being done on this, but nothing is far
> enough along to make a formal recommendation. We recommend not to use leap
> smear on public facing servers, but we know that people do it anyway. We
> are taking the point of view that if we inform operators that this may
> happen, they can ask the questions they need to ask ahead of time (or have
> a better clue what might be going on if one of their upstream servers
> disagrees with the others over the leap second.)
>

--SD: I suspected that was true. You might also point out what you told me
- there's no way to detect that an upstream server has started using leap
smearing, except by asking.

Thanks for everything else!

Spencer

> it would be helpful to me, to explain why this requirement is included. I
> can imagine a couple of reasons, but I'm guessing.
>
> --DPR: We included it as a simple check against setting the time way too
> early that probably shouldn’t impact users
>
> I wonder if the SUIT working group has any drafts that are stable enough
> to be used as an informative reference in Section 6.1, "Updating Embedded
> Devices".
> --DPR: I don’t think anything there looks stable right now, but that looks
> like a good group to follow. Thanks for the tip!
>
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 20 Dec 2018 20:25:06 -0600

> used as an informative reference in Section 6.1, "Updating Embedded Devices".

I'm only the irresponsible AD, but IIRC things are not quite mature enough
yet.

-Benjamin