Subject: [Ntp] draft-ietf-ntp-using-nts-for-ntp-13

From: Marcus Dansarie <[email-masked]>
Date: Mon, 3 Sep 2018 20:58:46 +0200

All,

Here are some comments/questions/discussion topics regarding version 13
of the NTS draft from my readthrough and the discussions during the
interim meeting:

* The change of the server negotiation records and addition of an
ability for port negotiation is an improvement. However, the design of
the records and the requirements added make it impossible for the client
to supply a list of preferred NTP servers and for the NTS server to tell
the client that the supplied cookies can be used with more than one NTP
server. This in an unnecessary limitation of functionality. Daniel
mentioned that there were security concerns behind this change. I'm
obviously curious about what those are. Hopefully they can be mitigated
without the loss of functionality.

* The "NTPv4 Server Negotiation" and "NTPv4 Port Negotiation" records
could be merged into a single record with a 16 bit port field followed
by an ASCII-encoded host string. This would simplify implementations and
emphasize the fact that a host-port-pair uniquely identifies a server.

* The additional padding field in the "NTS Authenticator and Encrypted
Extension Fields" extension field and the reason for adding it was a
good catch by Daniel. While the worst case scenario in using this for an
amplification attack is only expected to be in the order of 15
additional bytes, this has to be seen in light of the fact that NTP
packets are only about 100 bytes in size. Thus, a successful
amplification attack could give the attacker a ~10% amplification. This
is certainly big enough to be attractive, since the effort required is
essentially zero. It should also be noted that most well-behaved clients
will likely select a nonce length of N_REQ anyways, making the size of
the additional padding field zero.

* Has there been a discussion on whether we should try to get a tcp port
in the User or System range for NTS? Unless there's a good reason not
to, I think we should try to go for a port allocation in the System range.

There's probably more that I've forgotten already. I'll get back to that
when I remember.

Kind regards,
Marcus Dansarie