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

[Neta R S <[e-mail]>]

Hi Roman,

Thanks for your feedback.
Please see me reply below (in blue).

Thanks,
Neta

On Wed, Jul 12, 2023 at 3:22 PM Roman Danyliw via Datatracker <
[e-mail]> wrote:

> 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.
>
As this comment was previously answered, I quote here my co-author’s answer:
“There was quite a bit of discussion in the NTP working group about whether
the document should be informational or experimental, and the decision was
to proceed with information. We believe that "informational" fits this
draft for two reasons: firstly, an experimental evaluation was performed by
the authors, and contributed to how Khronos is currently defined, and
secondly, Khronos can be implemented without affecting or compromising
interoperability with existing NTPv4 implementations. While the NTF
implementation is in progress, we believe it should not affect the intended
status of the current document.”
>
>
> ** IDnits reported:
>   == Unused Reference: 'RFC2119' is defined on line 560, but no explicit
>      reference was found in the text
>
Thanks, I removed it.

>
> ** I don’t fully understand what a “watchdog” is.  It would be helpful to
> clarify what is being described and the notional implementation mechanism.
>
I added clarification in the introduction that a watchdog is simply a
background monitoring application. In our case it guards against time
shifting attacks.

>
> -- 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?
>
Khronos is an algorithm designed by this draft to be implemented alongside
any given NTP client (such as NTPv4). Khronos implementation should be
capable of monitoring the local time in a machine and if needed fixing it.
We leave this as implementation detail whether any specific implementation
adaptations are required to pair Khronos with a given NTP client in
different operating systems.
>
>
> ** 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”?

A value of “10 times NTP interval” was provided assuming the NTP poll
interval is within its default range.

>


> ** 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?
>
In general, the smaller this interval the more up to date entries will be
in the local pool, but the few hundreds of DNS queries to the pool address
will be performed at a higher rate. In the example provided in section 3.1,
it is explained that setting it to one month will result in at most 10 DNS
queries per day.

>
> ** 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, I fixed it.