Re: [auth48] AUTH48: RFC-to-be 9523 <draft-ietf-ntp-chronos-25> for your review

[Tal Mizrahi <[e-mail]>]

Dear RFC Editor Team,

Thanks for your work on this document.

One comment beyond the comments Neta already sent:
The following line appears in two places in Section 8:
Contact Martin Langer:[e-mail]

This is a typo, as the name does not match the email address.

Thanks,
Tal.

On Sat, Dec 23, 2023 at 12:36 AM <[e-mail]> wrote:
>
> Authors,
>
> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>
> 1) <!--[rfced] Please review our updates to Section 2.1 "Terms and
>      Abbreviations".  In the original, the expansions of abbreviations
>      and document titles were intermixed.  If the current text does
>      not suit, please let us know any objections.    -->
>
>
> 2) <!--[rfced] Should "rate" be added to the second sentence to match the
>      first?
>
> Original:
>      |    B     | An upper bound on the client's clock error rate    |
>      |          | (ms/sec).                                          |
>
>      |   ERR    | An upper bound on the client's clock error between |
>      |          | Khronos polls (ms).
>
>
> Perhaps:
>      |    B     | An upper bound on the client's clock error rate    |
>      |          | (ms/sec).                                          |
>
>      |   ERR    | An upper bound on the client's clock error rate    |
>      |          | between Khronos polls (ms).
>
> -->
>
>
> 3) <!--[rfced] Does the following suggested text correctly capture your
>      intent?  if not, please let us know how we may rephrase.
>
> Original:
>    Calibration is performed at the first time the Khronos is executed,
>    and also periodically, once in a long time (every two weeks).
>
> Perhaps:
>    Calibration is performed the first time Khronos is executed
>    and periodically thereafter (once every two weeks). -->
>
>
> 4) <!--[rfced] Is there a way to rephrase this sentence for clarity?  Is
>      the meaning that Khronos forces the DNS queries that are sent to
>      addresses of NTP pools to do the collecting of a group of all
>      received IP addresses?
>
> Original:
> To this end, Khronos makes DNS queries to addresses of NTP pools
> collect the union of all received IP addresses.
>
> -->
>
>
> 5) <!--[rfced] Should "selected to" read as "selected by the..."?  Or is
>      the meaning "selected to be part of the Khronos pool"?  Please
>      also review the capitalization of "Internet" here:
>
> Original:
>    In addition, servers can be selected to Khronos pool manually or by
>    using other NTP pools (such as NIST internet time servers).
>
> Perhaps:
>    In addition, servers can be selected by the Khronos pool manually or by
>    using other NTP pools (such as NIST Internet time servers).
>
> or
>
> Perhaps:
>    In addition, servers can be selected to be part of the Khronos pool
>    manually or by using other NTP pools (such as NIST Internet time
>    servers).
>
> -->
>
>
> 6) <!--[rfced] Would it be helpful for the readers to move the following
>      text to appear above the list in Section 3.2 (assuming it applies
>      to both bullet points)?
>
> Original:
>    (where w and ERR are as described in Table 1).
>
> Perhaps:
>    Khronos checks that the following two conditions hold for the
>    remaining sampled offsets (where w and ERR are as described in Table 1): -->
>
>
> 7) <!--[rfced] In the following, may we clarify what "to arrive to" was
>      communicating?
>
> Original:
> ...and the chances to arrive to repeated resampling
> are low (see Section 5 for more details).
>
> Perhaps:
> ...and the chances of repeated resampling
> are low (see Section 5 for more details).
>
> or
>
> Perhaps:
> ...and the chances of ending up with repeated resampling
> are low (see Section 5 for more details).
>
> -->
>
>
> 8) <!--[rfced] For the ease/interest of the reader, should a citation be
>      included for more information on the "Blufferboat attack"?  If
>      so, please let us know what you'd like to cite.  (We will assume
>      this reference entry would be informative unless we heard
>      otherwise.)
>
> Original:
> The threat model encompasses a broad spectrum of attackers, ranging
> from fairly weak (yet dangerous) MitM attackers only capable of
> delaying and dropping packets (for example using the Bufferbloat
> attack) to extremely powerful attackers who are in control of (even
> authenticated) NTP servers (see detailed security requirements
> discussion in [RFC7384]).
>
> -->
>
>
> 9) <!--[rfced] Is this a singular/plural change that should be made?  And
>      should this mention of a specific attack (MitM) be removed as it
>      is mentioned later in the same paragraph?
>
> Original:
> The following powerful attacker, including MitM is considered:
>
> [and then later]
>
> Original:
> The threat model encompasses a broad spectrum of attackers, ranging
> from fairly weak (yet dangerous) MitM attackers...
>
>
> Perhaps:
> The following powerful attackers, including MITM, are considered.
>
> Or
>
> Perhaps:
> The following powerful attackers are considered.
>
> -->
>
>
> 10) <!--[rfced] Section 5.3: This section suffers a bit from the fact that
>      two scenarios with two sub-scenarios are discussed.  This leads
>      to a decent amount of repeating text (and possible confusion for
>      the reader).
>
> We have updated the sub-cases to appear in ordered list form
> (indented) already, but we believe further updates to this section
> would make it easier for the reader to understand in a single read
> (i.e., naming the two scenarios, referring to the sub-cases by
> numbers, and breaking up the paragraph describing the sub-cases).
>
> Please see a further question below the suggested text.
>
> Please let us know if the following updates are agreeable:
>
> Perhaps:
>    Time samples that are at most w away from UTC are considered "good",
>    whereas other samples are considered "malicious".  Two scenarios are
>    considered:
>
>    *  Scenario A: Less than two-thirds of the queried servers are under the
>       attacker's control.
>
>    *  Scenario B: The attacker controls more than two-thirds of the queried servers.
>
>    Scenario A consists of two sub-cases:
>
>    1.  there is at least one good sample in the set of samples not
>        eliminated by Khronos (in the middle third of samples), and
>
>    2.  there are no good samples in the remaining set of samples.
>
>    In sub-case 1, the other remaining samples, including those
>    provided by the attacker, must be close to a good sample
>    (otherwise, the first condition of Khronos's system process in
>    Section 3.2 is violated and a new set of servers is chosen).  This
>    implies that the average of the remaining samples must be close to
>    UTC.
>
>    In sub-case 2, since more than a third of the initial samples were
>    good, both the (discarded) third-lowest-value samples and the
>    (discarded) third-highest-value samples must each contain a good
>    sample.  Hence, all the remaining samples are bounded from both
>    above and below by good samples, and so is their average value,
>    implying that this value is close to UTC [RFC5905].
>
>    In Scenario B, 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], the probability of this scenario is
>    extremely low, even if the attacker controls a large fraction (e.g.,
>    one-fourth) 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 2, where higher values indicate
>    higher improvement of Khronos over NTPv4 and are also proportional to
>    the expected time until a time-shift attack succeeds once.
>
>
>
> -->
>
>
> 11)  <!--[rfced] We had the following questions about the pseudocode in
>       Section 6:
>
> a) Please review the "type" attribute of each sourcecode element in
> the XML file to ensure correctness.
>
> We have updated to use "pseudocode" per the text introducing it.  If
> this is incorrect, please see below for further guidance:
>
> If the current list of preferred values for "type"
> (https://www.rfc-editor.org/materials/sourcecode-types.txt) does not
> contain an applicable type, then feel free to let us know. Also, it is
> acceptable to leave the "type" attribute not set.
>
> b) Please review the capitalization of "Then" and the use of a comma
> in the following portion of pseudocode:
>
> Original:
>       if (max(T) - min(T) <= 2w) and (|avg(T) - tk| < ERR + 2w) Then
>           return avg(T) // Normal case
>
> Perhaps:
>       if (max(T) - min(T) <= 2w) and (|avg(T) - tk| < ERR + 2w), then
>       return avg(T) // Normal case
>
> c) Please review the following line as it exceeds our character limit.
> Please let us know how we can update.
>
> Original:
> S = sample(m) //gather samples from (tens of) randomly chosen servers
>
> Perhaps:
> S = sample(m) //get samples from (tens of) randomly chosen servers
> -->
>
>
> 12) <!--[rfced] May we remove the "Implementation Status" section prior to
>      publication as an RFC?  Please see RFC 7942 for:
>
> "We recommend that the Implementation Status section should be removed
> from Internet-Drafts before they are published as RFCs."
>
> -->
>
>
> 13) <!--[rfced] We note that the title of the reference below is a
>      duplicate of [Khronos]. We have updated the reference as it
>      appears on the URL provided. Please let us know if any additional
>      changes are needed.
>
> Original:
> [Ananke_paper]
>            Perry, Y., Rozen-Schiff, N., and M. Schapira, "Preventing
>            (Network) Time Travel with Chronos", 2021,
>            <https://www.ndss-symposium.org/wp-content/uploads/
>            ndss2021_1A-2_24302_paper.pdf>.
>
> Current:
> [Ananke]
>            Perry, Y., Rozen-Schiff, N., and M. Schapira, "A Devil of
>            a Time: How Vulnerable is NTP to Malicious Timeservers?",
>            Network and Distributed Systems Security (NDSS) Symposium,
>            Virtual, DOI 10.14722/ndss.2021.24302, February 2021,
>            <https://www.ndss-symposium.org/wp-content/uploads/
>            ndss2021_1A-2_24302_paper.pdf>. -->
>
>
> 14) <!--[rfced] Please review the use of the following terms throughout
>      the document and let us know how you would like to proceed.
>
> Should the following be made uniform?
>
> time offset and Khnronos time offset
>
> watchdog vs. watchdog mode vs. watchdog mechanism
>
> -->
>
>
> 15) <!--[rfced] Please review the "Inclusive Language" portion of the
>      online Style Guide
>      <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>      and let us know if any changes are needed. For example, please
>      consider whether "man-in-the-middle" should be updated. We note
>      that "machine-in-the-middle" is used in the document. In the
>      following sentence, may we replace "man-in-the-middle" with
>      "MITM" (the abbreviation defined in this document for
>      "machine-in-the-middle")? Or would a different term be
>      appropriate here?
>
> Original:
>    We note that to accomplish
>    this, the attacker must have man-in-the-middle capabilities with
>    respect to the communication between each and every client in a large
>    group of clients and a large fraction of all NTP servers in the
>    queried pool.
>
> Perhaps:
>    We note that to accomplish
>    this, the attacker must have MITM capabilities with
>    respect to the communication between each and every client in a large
>    group of clients and a large fraction of all NTP servers in the
>    queried pool. -->
>
>
> 16) <!--[rfced] FYI - We have added expansions for abbreviations upon
>      first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please
>      review each expansion in the document carefully to ensure
>      correctness. -->
>
>
> Thank you.
>
> RFC Editor/mc/mf
>
> *****IMPORTANT*****
>
> Updated 2023/12/22
>
> RFC Author(s):
> --------------
>
> Instructions for Completing AUTH48
>
> Your document has now entered AUTH48.  Once it has been reviewed and
> approved by you and all coauthors, it will be published as an RFC.
> If an author is no longer available, there are several remedies
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>
> You and you coauthors are responsible for engaging other parties
> (e.g., Contributors or Working Group) as necessary before providing
> your approval.
>
> Planning your review
> ---------------------
>
> Please review the following aspects of your document:
>
> *  RFC Editor questions
>
>    Please review and resolve any questions raised by the RFC Editor
>    that have been included in the XML file as comments marked as
>    follows:
>
>    <!-- [rfced] ... -->
>
>    These questions will also be sent in a subsequent email.
>
> *  Changes submitted by coauthors
>
>    Please ensure that you review any changes submitted by your
>    coauthors.  We assume that if you do not speak up that you
>    agree to changes submitted by your coauthors.
>
> *  Content
>
>    Please review the full content of the document, as this cannot
>    change once the RFC is published.  Please pay particular attention to:
>    - IANA considerations updates (if applicable)
>    - contact information
>    - references
>
> *  Copyright notices and legends
>
>    Please review the copyright notice and legends as defined in
>    RFC 5378 and the Trust Legal Provisions
>    (TLP – https://trustee.ietf.org/license-info/).
>
> *  Semantic markup
>
>    Please review the markup in the XML file to ensure that elements of
>    content are correctly tagged.  For example, ensure that <sourcecode>
>    and <artwork> are set correctly.  See details at
>    <https://authors.ietf.org/rfcxml-vocabulary>.
>
> *  Formatted output
>
>    Please review the PDF, HTML, and TXT files to ensure that the
>    formatted output, as generated from the markup in the XML file, is
>    reasonable.  Please note that the TXT will have formatting
>    limitations compared to the PDF and HTML.
>
>
> Submitting changes
> ------------------
>
> To submit changes, please reply to this email using ‘REPLY ALL’ as all
> the parties CCed on this message need to see your changes. The parties
> include:
>
>    *  your coauthors
>
>    *  [e-mail] (the RPC team)
>
>    *  other document participants, depending on the stream (e.g.,
>       IETF Stream participants are your working group chairs, the
>       responsible ADs, and the document shepherd).
>
>    *  [e-mail], which is a new archival mailing list
>       to preserve AUTH48 conversations; it is not an active discussion
>       list:
>
>      *  More info:
>         https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>
>      *  The archive itself:
>         https://mailarchive.ietf.org/arch/browse/auth48archive/
>
>      *  Note: If only absolutely necessary, you may temporarily opt out
>         of the archiving of messages (e.g., to discuss a sensitive matter).
>         If needed, please add a note at the top of the message that you
>         have dropped the address. When the discussion is concluded,
>         [e-mail] will be re-added to the CC list and
>         its addition will be noted at the top of the message.
>
> You may submit your changes in one of two ways:
>
> An update to the provided XML file
>  — OR —
> An explicit list of changes in this format
>
> Section # (or indicate Global)
>
> OLD:
> old text
>
> NEW:
> new text
>
> You do not need to reply with both an updated XML file and an explicit
> list of changes, as either form is sufficient.
>
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text,
> and technical changes.  Information about stream managers can be found in
> the FAQ.  Editorial changes do not require approval from a stream manager.
>
>
> Approving for publication
> --------------------------
>
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
>
>
> Files
> -----
>
> The files are available here:
>    https://www.rfc-editor.org/authors/rfc9523.xml
>    https://www.rfc-editor.org/authors/rfc9523.html
>    https://www.rfc-editor.org/authors/rfc9523.pdf
>    https://www.rfc-editor.org/authors/rfc9523.txt
>
> Diff file of the text:
>    https://www.rfc-editor.org/authors/rfc9523-diff.html
>    https://www.rfc-editor.org/authors/rfc9523-rfcdiff.html (side by side)
>
> Diff of the XML:
>    https://www.rfc-editor.org/authors/rfc9523-xmldiff1.html
>
> The following files are provided to facilitate creation of your own
> diff files of the XML.
>
> Initial XMLv3 created using XMLv2 as input:
>    https://www.rfc-editor.org/authors/rfc9523.original.v2v3.xml
>
> XMLv3 file that is a best effort to capture v3-related format updates
> only:
>    https://www.rfc-editor.org/authors/rfc9523.form.xml
>
>
> Tracking progress
> -----------------
>
> The details of the AUTH48 status of your document are here:
>    https://www.rfc-editor.org/auth48/rfc9523
>
> Please let us know if you have any questions.
>
> Thank you for your cooperation,
>
> RFC Editor
>
> --------------------------------------
> RFC9523 (draft-ietf-ntp-chronos-25)
>
> Title            : A Secure Selection and Filtering Mechanism for the Network Time Protocol with Khronos
> Author(s)        : N. Rozen-Schiff, D. Dolev, T. Mizrahi, M. Schapira
> WG Chair(s)      : Dieter Sibold, Karen O'Donoghue
>
> Area Director(s) : Erik Kline, Éric Vyncke
>
>