|
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.
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
