Re: [Ntp] comments on draft-ietf-ntp-using-nts-for-ntp-23

Hello Sandy,

Thank you very much for your thorough review and all your insightful comments!

As Daniel mentioned in another thread, we are working on a new revision of the draft, were we intend to addresses these issues.

Since there were so many detailed comments, to be able to keep track of them and any discussions around them, I have now made “issues” of them, here: <https://github.com/dfoxfranke/nts/issues>
I have also started to insert comments from previous discussions, and pull requests to fix them.
Feel free to comment them there too.

Best regards,

Ragnar

> On 5 Mar 2020, at 15:57, Sandra Murphy <sandy@tislabs.com> wrote:
> 
> I realize that I did not include one concern about the security considerations.  Section 9.7 NTS Stripping talks about the client being deceived into reverting to plain NTP.  There’s no discussion of the server being deceived into responding with plain NTP.  An adversary who stripped the NTS extensions from the a NTP request would lead the server to reply without the expected NTS extensions in the response.  What should/would the client do if it receives a non-NTS enhanced response to a NTS enhanced request?
> 
> [Steve Bellovin would frequently suggest that there should be a way for a recipient to know to expect security protections to prevent such downgrade attacks.  I don’t think there is a way in this case.]
> 
> —Sandy
> 
>> On Mar 4, 2020, at 7:06 PM, Sandra Murphy <sandy@tislabs.com> wrote:
>> 
>> I am not an NTP participant but curious about vulnerabilities of NTP so I looked at NTS on last Fri, 28 Feb.
>> 
>> Unfortunately, that was the last day of the IETF last call, so I have comments and they are arriving after the last call.
>> 
>> So give these comments the consideration they deserve - they come late from someone who lacks context.
>> 
>> Detailed comments attached.  Overall comments here:
>> 
>> Section 1 makes it clear that there is an intentional separation between the NTS-KE server and the NTP server, although it is allowed that both services could be resident on the same host.  Figure 1 also makes it appear that the NTS-KE server may be associated with a large number of NTP servers, with unspecified means of communicating between them.  Reading through, I was struck by how much the NTS-KE server must know about the NTP server - in Section 4.1.5 what algorithms it would support, in Section 6 the keying material it would accept.  I was puzzled at how this could work in the post.ntp.org set of volunteer NTP servers.  Then in Section 6, I saw a reference to “load-balanced cluster”, which would easily account for the NTS-KE server’s knowledge of the NTP servers’ configurations.  More explanations of the supportable (current and potential) architectures would be very helpful.  
>> 
>> I believe it would be helpful for the implementers to have an explicit list of what the NTS-KE server must know about the NTP servers (address, algorithms supported, shared keys in use, cookie construction, protocol IDs accepted, anything else?) and what the communication between the NTS-KE server and the NTP server must provide (what Figure 1 calls “Shared cookie encryption parameters”).
>> 
>> Some of the text concerns the interactions with the NTS-KE server, some concerns the interactions with the NTP server.  The word “server” is used throughout.  There are cases where it is not clear which type of server is meant from context.
>> 
>> I found several cases where I was not sure what the error conditions should be handled, when requirements are not met, when an exchange fails, when an error condition is received, etc.  In some sections, the receiver’s action upon receiving one message is explained but for other messages is not.  
>> 
>> Normative language: There are places where the text says “should” not “SHOULD” and it was not clear the RFC2119 language was intended.  In particular, Section 6 uses “should” many times.  Perhaps that was intentional since this section is not normative.  I’m not sure what should (sic) be the usage in that case.  “In general” appears many times, which begs the question of when it is or is not the case.  On page 21, the text says “In general, however, the server MUST”.  I’m not sure what that means to an implementer.  The following language talks about exceptions, so perhaps the “In general” means “where there is no exception”.
>> 
>> The document sets up an IANA registry for the Protocol ID.  Is it necessary to stipulate what a specification of a new Protocol ID must include?  Must it include a cookie format, for example?
>> 
>> On page 21, the caption for Figure 5 should be “NTS-protected NTP Time Synchronization Messages”.  It is an NTP exchange, not an NTS exchange.
>> 
>> Section 9.4 page 36 - Is there a reference for “NTP_PHASE_MAX?”  A web search found only references to this draft and to a “kernel constant” in various *nx man pages.
>> 
>> In Section 6, the identifier “I” is used as a salt.  RFC5869 says the salt is random.  Should the text about choosing the “non-secret, unique” identifier mention random / unpredictable as well?
>> 
>> —Sandy
>> <draft-ietf-ntp-using-nts-for-ntp.detailedcomments.txt>
>> 
>> 
>> _______________________________________________
>> ntp mailing list
>> ntp@ietf.org
>> https://www.ietf.org/mailman/listinfo/ntp
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp