[Ntp] Roman Danyliw's No Objection on draft-ietf-ntp-chronos-20: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-ntp-chronos-20: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



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

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/