A Secure Selection and Filtering Mechanism for the Network Time Protocol with Khronos
draft-ietf-ntp-chronos-25

- I support Paul Wouters' DISCUSS.

- I agree with Éric Vyncke's comments and in particular the one about "specifies".

- Note that the term "man-in-the-middle" is somewhat dated, perhaps consider something like "on-path attacker"? [1]

- Although you provide a reference to the security properties analyzed for Khronos, you don't mention to what, if any, extent Khronos might be expected to produce false positives, and what deleterious effect this might have on expected time synchronization accuracy. Have you analyzed this? Section 6 gives the superficial appearance of speaking to this question, but doesn't really answer it as far as I can tell.

- I don't follow the pseudocode idiom you're using. You use a Pascal-like assignment operator of := on most lines, but in the second and third lines you use the = operator. I guess that's not assignment. It's not a test. So what is it?

[1] https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/

I support Paul's DISCUSS position.

Thanks for addressing the concerns raised by me and other ADs. I have updated my ballot to No Objection.

Thank you to Benjamin M. Schwartz’s SECDIR review.

I support Paul Wouter’s DISCUSS position.

** Per the document status, was there WG discussion on making this document experimental status instead of informational? I don’t have a sense of how much field validation there is of this approach.

** IDnits reported:
  == Unused Reference: 'RFC2119' is defined on line 560, but no explicit
     reference was found in the text

** I don’t fully understand what a “watchdog” is.  It would be helpful to clarify what is being described and the notional implementation mechanism.

-- is “Khronos” an algorithm and this is guidance to NTP client implementers?  Is there a “Khronos application” and an unmodified “NTP application”?

-- Is there any interoperability being described here?

-- Per Warren’s ballot, when “Khronos” detects malfeasance, how does it interact with OS or what new behavior does it introduce to a NTP client?

** Section 3.
   Based on
   empirical analyses, to minimize the load on NTP servers while
   providing high security, the Khronos poll interval should be around
   10 times the NTPv4 poll interval

Since the guidance is “should be around 10 times”, when would you deviate from “10 times”?

** Section 3.1
   Calibration is performed at the first time the Khronos is executed,
   and also periodically, once in a long time (e.g., every few weeks/
   months).

“Every few weeks” to “months” seems like a large spread of time.  What guides the calibration window?

** Section 3.2.
   Note that the randomness of the
   server selection is crucial for the security of the scheme and
   therefore any Khronos implementation should use secure randomness
   implementation such as used for encryption key generation.

If “randomness of the server selection is crucial”, why isn’t it mandatory for Khronos implementations to use a secure randomness implementation?  Specification s/implementations should use/implementations must use/

Thanks for working on this specification. Thanks to Tommy for his TSVART review.

I have not find TSV related issues in my review.

# Éric Vyncke, INT AD, comments for draft-ietf-ntp-chronos-20

Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Dieter Sibold for the shepherd's detailed write-up including the WG consensus *but* it lacks the justification of the intended status. 

Other thanks to Geoff Huston, the DNS directorate reviewer, please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-ntp-chronos-14-dnsdir-lc-huston-2023-06-08/(and I have read Neta's reply)

Other thanks to Tim Chown, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-ntp-chronos-17-intdir-telechat-chown-2023-07-03/ (and I have read the exchange between Tim and the authors)

I hope that this review helps to improve the document,

Regards,

-éric


# COMMENTS

## Chronos or Khronos

Just curious about the use of Khronos in the text and Chronos in the filename and in the academic paper ;-)

## Unused reference

Please remove RFC 2119 from the normative references list as it is not used.

## Intended status

I would have assumed that this I-D would have been experimental rather than informational. *NO* justification/explanation is given in the shepherd write-up :-(

## Abstract

s/This document specifies an extension to the NTPv4 client/This document describes a companion application to the NTPv4 client/. Being informative, it cannot really 'specify' and 'extension' could be understood as protocol update. Let's be clear ;-)

As a side note, is the code for this Khronos 'extension' public and available somewhere ? This could be useful.

## Section 3.1

I have in mind that pool.ntp.org authoritative DNS servers answers are influenced by the IP address of the resolver. If this is the case, then isn't the 'Khronos pool' a little bias to a region?

## Section 4.1

`However, adding an authentication layer (e.g., NTS [RFC8915]) to Khronos will enhance its security guarantees` While probably true, I wonder whether a future-looking statement like this one has a place in the security considerations.

I also wonder about the attack (2) as an ISP could easily intercept all UDP/123 packets and delay them. In this case, Khronos would not help too much.

Thanks for this document, and to Tommy Pauly for the TSVART review.

From the Introduction:
"Khronos can be integrated into NTPv4-compatible servers as an NTPv4 client's "watchdog" against time shifting attacks."

From reading the rest of this document, I don't understand how any part of this spec affects servers at all.

Hi,

Thanks for this document.

I support Paul's discuss.

Minor level comments:

(1) p 0, sec 

   Since it does not affect the wire protocol, the Khronos mechanism is
   applicable to current and future time protocols.

Saying it is applicable to future time protocols seems to be quite a strong assertion to make.  E.g., would it still be applicable if future time protocols had a very different protocol structure?


(2) p 3, sec 1.  Introduction

   Khronos introduces a watchdog mechanism that maintains a time offset
   value that is used as a reference for detecting attacks.  The time
   offset value computation differs from the current NTPv4 in two key
   aspects.  First, Khronos periodically communicates, in each Khronos
   poll interval, with only a few (tens) randomly selected servers out
   of a pool consisting of a large number (e.g., hundreds) of NTP
   servers, thereby providing high security while minimizing the load on
   the NTP servers.  Second, Khronos computes "Khronos time offset"
   based on an approximate agreement technique to remove outliers, thus
   limiting the attacker's ability to contaminate the "time samples"
   (offsets) derived from the queried NTP servers.  These two elements
   of Khronos's design provide provable security guarantees against both
   man-in-the-middle attackers and attackers capable of compromising a
   large number of NTP servers.

Bits of the introduction text feel a bit repetitive.


(3) p 9, sec 4.3.  Security Analysis Overview

   In the second scenario, where the attacker controls more than 2/3 of
   the queried servers, the worst possibility for the client is that all
   remaining samples are malicious (i.e., more than w away from UTC).
   However, as proved in [Khronos_paper], the probability of this
   scenario is extremely low even if the attacker controls a large
   fraction (e.g., 1/4) of the n servers in the local Khronos pool.
   Therefore, the probability that the attacker repeatedly reaches this
   scenario decreases exponentially, rendering the probability of a
   significant time shift negligible.  We can express the improvement
   ratio of Khronos over NTPv4 by the ratios of their single shift
   probabilities.  Such ratios are provided in Table Table 2, where
   higher values indicate higher improvement of Khronos over NTPv4 and
   are also proportional to the expected time till a time shift attack
   succeeds once.

I'm not an NTP or security expert, but if the NTP clients were attached to a stub network (e.g., perhaps connected to Wi-Fi in a coffee shop), then is it plausible that an on-path attacker (e.g., that had control of the Wi-Fi gateway router) would be able to delay all downstream NTP packets towards the client, perhaps randomly by 30-45 seconds?  Would this allow a single compromise in the network to bypass the protection that Khronos is offering?


(4) p 12, sec 9.2.  Informative References

   [Khronos_paper]
              Deutsch, O., Schiff, N.R., Dolev, D., and M. Schapira,
              "Preventing (Network) Time Travel with Chronos", 2018,
              <https://www.ndss-symposium.org/wp-
              content/uploads/2018/02/ndss2018_02A-2_Deutsch_paper.pdf>.

This has been listed as informative, but if you are leaning on it for your security considerations at all, it might be better being normative.



Nit level comments:

(5) p 8, sec 4.1.  Threat Model

   Moreover, Khronos uses randomness to independently select the queried
   servers in each poll interval, making it imune to attackers that
   aware of its implementation and past communications.

imune -> immune.  The end of the sentence also doesn't scan.

Regards,
Rob