Subject: [Ntp] Comments on NTS - Aanchal Malhotra

From: Aanchal Malhotra <[email-masked]>
Date: Tue, 5 Sep 2017 09:35:26 +0200

Hi,

Sorry for the late review. I am unwell and so away from emails.  I think
the document is great but few sections remain inadequately explained. I
would like to do another pass and may be even have another WG call before
going forward. Please read my following comments.

*Section 1.1*

Aren't the objectives of NTS different for different modes? e.g.

1) The following objective is not true for client/server mode, since the
server does not have this privilege.

"
*Replay prevention: Implementations may detect when a received time
synchronization packet is a replay of a previous packet."*
2) The usage of the terms client and server in the following objective is
confusing. Does it refer to NTP client/server mode? Does it refer to any
implementation?

"*Request-response consistency: Client implementations may verify that a
time synchronization packet received from a server was sent in response to
a particular request from the client*."

Similar problems with the 'Unlinkability' and 'Scalability' objectives. I
think it would be worth stating separately the Objectives of NTS for
different modes. And make use of the terms client and server to only refer
to NTP's client server mode participants.
In fact the first para of section 1.2 could be used to justify the
different objectives of NTS for different modes and could be placed
before/in section 1.1

*Section 1.2*

"*it is harmless for servers to process replayed packets*"

I do not agree with the statement above. In addition to Sharon’s objection,
in NTS, the server can be DoSd in terms of resources by replaying query
packets because it has to do more work than normal NTP.

Minor comment: Section 1.2 The last and second to last paras are 2 parts of
the same thing. Putting them in 2 points makes it more readable.

*Section 4.*

I feel like this section requires more discussion on the length of
sessions. Like what is the typical frequency of symmetric peer exchanges
and correspondingly what is the typical length of a DTLS session? When will
it time out? How often do the peers have to re-establish DTLS session? How
do they know? Similar questions for control mode and client/server mode.

Overall, this section needs more explanation.

“*The two endpoints carry out a DTLS handshake in conformance with Section
3, with the client offering (via an ALPN [RFC7301] extension), and the
server accepting, an application-layer protocol of "ntp/4"*.

Again term client/server is overloaded. This is supposed to be DTLS client
and DTLS server and not NTP mode3/4 client server.

Also, add “First” in the beginning of sentence.

*Section 5*
The interpretation of critical bit C seems confusing. How is the figure 2
parsed by the client? The interpretation of C is Record Type dependent.

Why in section 5.1.5 "C is MAY and not MUST? How is this bit interpreted
when it is 0 or when it is 1?

Also, in section 5.1.6  "C SHOULD NOT be set". Again, what does the client
do if he finds it set?

IMO, this section is very high level description and not very fluent from
implementation point of view. As written now, it is very difficult to
follow. May be we can have a table with all possible combinations of C and
record types and the corresponding action taken by client or the server.

*Section 6*

“*Upon receiving an NTS-protected response, the client MUST verify that
the Unique Identifier matches ……… which sent the NAK and initiate a fresh
NTS-KE handshake.*”

This section is understated and requires much more detailed explanation.
The order in which client performs the checks and the corresponding changes
it makes to the internal state variables is important to mention as this
has lead to several implementation flaws in the past. For instance,

1) If the UID match passes, the client checks for crypto. Then there are
two cases:

               a) If crypto is fine, client processes the packet and stops
listening for any response corresponding to this UID.

               b) If crypto fails, it does not process the packet and stops
listening for the response corresponding to this UID.

2) If the UID match fails, the client should not check for crypto. AND must
still keep listening for the packets corresponding to the stored UID.
(Otherwise an easy off-path attack.)

This is just an example. There are several other cases and it is IMPORTANT
to mention the state variable changes in EACH case. We should discuss/talk
about it and sort this out.

Thanks,
Aanchal Malhotra.
_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp