Re: [auth48] AUTH48: RFC-to-be 9523 <draft-ietf-ntp-chronos-25> for your review
rfc-editor@rfc-editor.org Fri, 22 December 2023 22:36 UTC
Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C90C14F6BF; Fri, 22 Dec 2023 14:36:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.657
X-Spam-Level:
X-Spam-Status: No, score=-5.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CTE_8BIT_MISMATCH=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, URI_WP_DIRINDEX=1] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fis5uxxNGYq6; Fri, 22 Dec 2023 14:36:34 -0800 (PST)
Received: from rfcpa.amsl.com (rfcpa.amsl.com [50.223.129.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBD4CC151076; Fri, 22 Dec 2023 14:36:32 -0800 (PST)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 986311BA40B2; Fri, 22 Dec 2023 14:36:32 -0800 (PST)
To: neta.r.schiff@gmail.com, danny.dolev@mail.huji.ac.il, tal.mizrahi.phd@gmail.com, schapiram@huji.ac.il
From: rfc-editor@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, ntp-ads@ietf.org, ntp-chairs@ietf.org, dsibold.ietf@gmail.com, ek.ietf@gmail.com, auth48archive@rfc-editor.org
Content-type: text/plain; charset="UTF-8"
Message-Id: <20231222223632.986311BA40B2@rfcpa.amsl.com>
Date: Fri, 22 Dec 2023 14:36:32 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/31awkLzk_w-dh1TWqr5PyeURhkQ>
Subject: Re: [auth48] AUTH48: RFC-to-be 9523 <draft-ietf-ntp-chronos-25> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Dec 2023 22:36:38 -0000
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 * rfc-editor@rfc-editor.org (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). * auth48archive@rfc-editor.org, 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, auth48archive@rfc-editor.org 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
- [auth48] AUTH48: RFC-to-be 9523 <draft-ietf-ntp-c… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9523 <draft-ietf-n… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9523 <draft-ietf-n… Neta R S
- Re: [auth48] AUTH48: RFC-to-be 9523 <draft-ietf-n… Tal Mizrahi
- Re: [auth48] [AD] AUTH48: RFC-to-be 9523 <draft-i… Madison Church
- Re: [auth48] [AD] AUTH48: RFC-to-be 9523 <draft-i… Tal Mizrahi
- Re: [auth48] [AD] AUTH48: RFC-to-be 9523 <draft-i… Madison Church
- Re: [auth48] [AD] AUTH48: RFC-to-be 9523 <draft-i… Neta R S
- Re: [auth48] [AD] AUTH48: RFC-to-be 9523 <draft-i… schapiram
- Re: [auth48] [AD] AUTH48: RFC-to-be 9523 <draft-i… Madison Church
- Re: [auth48] [AD] AUTH48: RFC-to-be 9523 <draft-i… Madison Church
- Re: [auth48] [AD] AUTH48: RFC-to-be 9523 <draft-i… Madison Church
- Re: [auth48] [AD] AUTH48: RFC-to-be 9523 <draft-i… Madison Church
- [auth48] [AD - Erik ] AUTH48: RFC-to-be 9523 <dra… Sandy Ginoza
- Re: [auth48] [AD - Erik ] AUTH48: RFC-to-be 9523 … Erik Kline
- Re: [auth48] [AD - Erik ] AUTH48: RFC-to-be 9523 … Neta R S
- Re: [auth48] [AD - Erik ] AUTH48: RFC-to-be 9523 … Madison Church