Hi Ben, Many thanks for the comments. Regarding the question about the intended status of the document, 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 informational. 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. Cheers, Tal. On Mon, Jul 3, 2023 at 5:01 PM Ben Schwartz <bemasc@xxxxxxxx> wrote: > > Thanks for following up. Is the Khronos behavior considered fully supported and stable in an NTF-maintained codebase? If not, I still think "Experimental" may be the appropriate document status. > > --Ben Schwartz > ________________________________ > From: Neta R S <neta.r.schiff@xxxxxxxxx> > Sent: Saturday, July 1, 2023 9:50 PM > To: Benjamin Schwartz <ietf@xxxxxxxxxx> > Cc: secdir@xxxxxxxx <secdir@xxxxxxxx>; draft-ietf-ntp-chronos.all@xxxxxxxx <draft-ietf-ntp-chronos.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>; ntp@xxxxxxxx <ntp@xxxxxxxx> > Subject: Re: Secdir last call review of draft-ietf-ntp-chronos-16 > > Hi Benjamin, Thank you for your comments. I am sorry for the late response. Please see my reply inline below (in blue). Best, Neta On Thu, Jun 22, 2023 at 10: 01 PM Benjamin Schwartz via Datatracker <noreply@ ietf. org> wrote: Reviewer: Benjamin > ZjQcmQRYFpfptBannerStart > This Message Is From an Untrusted Sender > You have not previously corresponded with this sender. > > ZjQcmQRYFpfptBannerEnd > Hi Benjamin, > > Thank you for your comments. > I am sorry for the late response. > Please see my reply inline below (in blue). > > Best, > Neta > > On Thu, Jun 22, 2023 at 10:01 PM Benjamin Schwartz via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Benjamin Schwartz > Review result: Has Nits > > This draft describes an improved variant of the NTP client state machine that > can more reliably reject servers that are hostile or are under attack. It is > effectively a summary of a more detailed research paper. Overall, the proposal > appears reasonable, and is presented clearly. However, I do have two concerns > to note: > > 1. The document's status is "Informational". The text is largely a summary of > a more detailed academic research paper. The proposal has been implemented, > but seemingly only in an academic demonstration codebase. If the Khronos > behavior has not yet been implemented in a widely used NTP client codebase, I > think the "Experimental" status would likely be more appropriate. > > >> Khronos is currently developed as a NTF project (see https://khronos.nwtime.org/). > > > 2. The document claims to defend against MITM attackers, but it also notes that > the defense only applies to attackers that can interfere with some fraction of > NTP server access. The security section should be expanded to note explicitly > some attackers who are out of scope. One such attacker appears to be the > "nearby MITM", who can selectively block any of the client's traffic. > > >> Thanks for your comment. We added a clarification in the threat model section. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
