[Ntp] WGLC comments on draft-ietf-ntp-using-nts-for-ntp-14

[Marcus Dansarie <[e-mail]>]

All,

Ragnar and I spent a couple of hours yesterday going over NTS4NTP draft
14. Overall, we are very happy with the current state of the draft. Our
remaining concerns and a few general comments are as follows:

* In Section 1.1, we would still like resilience to be an express
objective of NTS. A possible wording could be "Attacks on or faults in
parts of the NTS infrastructure should not completely prohibit clients
from performing time synchronization. In particular, security
enhancements to the NTP protocol should not increase the protocol's
ability to withstand attacks."

* Re Section 3, we still feel that TLS 1.3 should be the lowest
acceptable TLS version. It is certainly true that requiring TLS 1.3
would probably limit short term adaption of NTS. Our opinion, however,
is that concerns for for the short term should not take priority over
the long term where this could lead to servers having to support TLS 1.2
for a long time if TLS 1.2-only client implementations were to emerge
after the draft's adaption as an RFC.

* Our suggested NTP Server Negotiation record from draft-dansarie-nts-00
has been reworked by Daniel Franke into Sections 4.1.7 and 4.1.8
following comments in previous WG meetings. After thorough discussion,
Ragnar and I now agree that the design in current draft is sound and
that there is no need for the NTS-KE protocol to support lists of
preferred/assigned servers in server/port negotiation records. Such
lists would add to protocol complexity while only satisfying a fringe
requirement that can be achieved on the implementation side without this
addition. We only have one minor comment to the wording: In Section
4.1.7, paragraph 2: "If no record of this type is sent, the client SHALL
interpret this [...]", we believe that SHALL is to strong of a
requirement and that a SHOULD would suffice.

* In Section 5.6, we support the addition of an additional padding field
and the reasoning behind it.

* In Section 7.1, the service name has been changed to "ntske". We
support this. The section reserves a TCP port only for NTS-KE. It has
been suggested to us that it is customary to register both TCP and UDP
ports with the same number, but we're unsure what the current practice
is. Considering that NTP's registered port is in the system port range,
we think that we should try to get an NTS-KE port in the same range,
unless there are strong reasons not to.

* In Section 9.3, it is suggested that clients should "not process time
packets from servers if the time computed from them falls outside the
validity period of the server's certificate." We believe that there is a
risk that this could be interpreted as meaning that clients should
reperform an NTS-KE handshake upon expiry of the certificate that was
used by the NTS-KE server to provide the client with its initial supply
of cookies. In the worst case, this could lead to an accidental DoS
attack as many clients try to perform a new NTS-KE handshake at the
expiry time of a server's old certificate. We suggest adding a sentence
like "Clients SHOULD NOT perform a new NTS-KE handshake solely based on
the fact that the certificate used by the NTS-KE server in a previous
handshake has expired, if the client has previously received valid NTS
protected NTP replies that lie within the certificate's validity time."

* Since there is a current draft that attempts to solve the problem
described in Section 9.4, adding a reference there to
draft-schiff-ntp-chronos-01 could be a good idea.

In conclusion: We have no major objections to the draft at this point.
With the exception of our comment on Section 9.3, none of our comments
are of great importance to us and we will yield if there is no
agreement. Our concerns regarding Section 9.3 need to be addressed in
one way or another.

We would like to thank everyone who have contributed to the draft and
made the effort to read and comment on it. We look forward to your
comments on our suggestions.

Kind regards,
Marcus Dansarie and Ragnar Sundblad