Network Time Security for the Network Time Protocol
draft-ietf-ntp-using-nts-for-ntp-28

(tried to de-duplicate COMMENTs with Ben’s)

I support Ben Kaduk’s DISCUSS position.

** Section 3. Since NTS is a green field design, is there are reason to be backward compatible to TLS version <1.3?

** Section 4.1.7.  Consider using RFC900 as a reference for IPv4 dotted decimal notation.

No objection, but wow, that is a through review by Ben - thanks for saving me from the work :-)

Thank you for the work put into this document. It is easy to read (and this is important) and it has multiple implementations. Section 9.4 "Initial Verification of Server Certificates" is indeed a real chicken and egg issue and quite classical. I am also trusting the security AD and SECDIR for the security aspects of the protocol.

Please find below some non-blocking COMMENTs and NITs. An answer will be appreciated though ;-)

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1.1 --
Authentication is of course a desirable property but I would have assumed that the time accuracy is even more important. A shift in time -- even minor -- by one compromised party would even be more important.

-- Section 1.2 --
Does NTP have a "a broadcast mode" or "a multicast mode" ? Notably as the former does not exist for IPv6 ;-)

Is it really true that "it is harmless for stateless servers to process replayed packets" as it will have an impact on the server CPU even if stateless. Obviously, a DoS on a stateless server is less effective but writing "harmless" is too strong IMHO.

In Figure 1, should there be a comma between "Shared cookie" and "encryption parameters" between NTS-KE & NTP servers ?

-- Section 3 --
I really wonder why TLS 1.3 is not a MUST (e.g., AFAIK TLS 1.3 is supported by openssl) but I will trust the security AD on this topic.

-- Section 4 --
What was the reasoning behind the decision of not using a simple REST API here? This exchange is executed once, so, the overhead is not really important.

-- Section 4.1 --
Is there a specific order for the record? (except for the 'end of message') ?

-- Section 4.1.1. --
What is the expected behavior of the NTS-KE client/server when this record is not the last one or is missing?

-- Section 4.1.3 & 4.1.4 --
Should there be a IANA registry for those error / warning codes? Esp if the record type can be extended via IANA registry so new error / warning case will be required ?

-- Section 4.1.7 --
While I am a little surprised to see IPv4/IPv6 addresses transmitted as ASCII strings, please also refer to RFC 5952 for the canonical representation of an IPv6 address.

The sentence "If a label contains at least one non-ASCII character, ..." probably applies to the FQDN but it would be clearer to say so.

Should the FQDN be terminated by a final dot ?

What is the expected behavior of the client when the FQDN has several IPv4 and several IPv6 addresses ?

Is it expected that the FQDN of the NTP servers can resolve to several IP addresses based on availability, load balancing, or client mobility ? If so, how are cookies synchronized? Else, let's be specific in the document.


== NITS ==

-- Section 7.6 --
The table will gain clarity by adding an empty line between entries.

Are there individual drafts that should be tagged as being replaced by this document?  It looks like draft-dfranke-nts may be one of them.

Thanks for a well-written document.  I have one small, non-blocking question:
Section 4.1.6 says, “the Critical Bit SHOULD NOT be set.”  Why “SHOULD NOT” rather than “MUST NOT”?  Under what conditions might a server set it, and why?  (Similar question for other “SHOULD NOT set” cases in the document.)

Thanks for addressing my Discuss and Comment points!

Thanks for addressing my discuss issues and comment.

Thanks for addressing my discuss points about retries recommendations!


------
Old comments for the record as only partially addressed yet:
-----

In addition to Ben's discuss point on ports which I would also like to see the answer to, one more question: My understanding is that the TCP port (123) for NTP is not used and will likely never be used in future. Why are you not using that port for NTS-KE, as NTS-KE is using TCP? 

A couple more small questions:
1) Sec 4.1.3:
"The Critical Bit MUST be set."
If you set the Critical Bit for error records, that would only mean that a receiver could send another error in response to that error which again has the critical bit set which then could cause another error, and it would go on forever. Yes, this case should never happen as all its-ke implementations must support error records but maybe it's safer to just not set the critical bit?

2) Sec 4.1.4: I don't really understand the idea of the Warning record. There are no code points defined and there is no explanation given what this could be used for. Especially what should a client do that received a warning? Why is the error record not sufficient?

3) Sec 4.1.5: "   If the NTS Next Protocol Negotiation record offers Protocol ID 0 (for
   NTPv4), then this record MUST be included exactly once. "
In this case, I guess the critical bit should/MUST be also set to 1?

4) Sec 5.7:
"1280 octets is
   the minimum prescribed MTU for IPv6 and is in practice also safe for
   avoiding IPv4 fragmentation.  Nonetheless, senders SHOULD include
   fewer cookies and placeholders than otherwise indicated if doing so
   is necessary to prevent fragmentation."
RFC8085 says "For IPv4, EMTU_S is the smaller of 576 bytes and the
   first-hop MTU [RFC1122]."
Maybe it would be appropriate to note that.