Subject: [Ntp] Message from DLM about NTS4NTP

From: Harlan Stenn <[email-masked]>
Date: Wed, 1 Aug 2018 22:23:22 -0700

Dave asked me to post this on his behalf:

reference: xxx autokey3.txt (HMS: I'll post this next)

Folks,

First, let me apologize for my absence at IETF meetings and telecoms. I
have recently lost all my vision and am still getting used to it. I can
compose and read email and most web sites, but installing programs and
activating internet VOIP is mostly a lose.

This message represents my comments on the progress of the NTS for NTP
security model. While the proposed model is appropriate for
client/server mode, it is wickedly complicated and full of often
frivolous options. A serious deficit is that it addresses only the
client/server mode and not the other modes frequently necessary in practice.

A fundamental difference between the current NTS document and the NTP
document posted on the reference above is the design of the basic
application layer. The NTS document embeds the NTP packet with
additional extension fields and other data. My document avoids this
entirely; the NTP packet includes only the NTP header and MAC. This
design is consistent with RFC 5905 and the current reference
implementation. This solves the backwards compatibility problem,at least
for symmetric shared hash keys, as well as provide a foundation for the
handshake protocol.

The handshake protocol is layered in four exchanges with simple
extension fields. The exchanges are self-authenticated, idempotent and
restartable in case of error. The handshake protocol completely
disappears once the shared hash key is computed and authenticated.

While the NTS document says nothing about the certificate trail
verification, the NTP document includes a description of how the trail
is augmented and verified at each step.

The treatment of broadcast mode in other than this document is not
sustainable in current practice. The basic design requires a two way
path between server and client and loosely synchronized clock, which
cannot be sustained in the current specification and reference
implementation. In addition, provisions have to allow more than one
broadcast server on the same wire as the client.

There is no need for TCP for the handshake protocol, since the NTP
protocol consists of simple request/response exchanges. The handshake
protocol goes away after completing and verifying the shared hash key.
additional comments and explanations are in the document.

I am not certain about the fate of this document, but in any case it can
serve as an alternate to certify the NTS document provides equivalent
functionality. Since the NTS document applies only to client server
mode, I assume that at least two more NTS documents are necessary; one
for symmetric mode and the other for broadcast mode.

David L. Mills
harlan stenn
-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Marcus Dansarie <[email-masked]>
Date: Tue, 21 Aug 2018 20:36:44 +0200

All,

My apologies for the late reply to this. It's been on my to-do list for
a while now.

I don't agree with the sentiment that the current NTS draft is "wickedly
complicated". It is as complicated as it needs to be. The main driver of
complexity are the ambitions security goals. I believe they are
justified for NTP, which is a fundamental Internet service that
literally billions of people depend on. Moreover, NTS will make future
improvements to the security of network time protocols easy and
backwards compatible.

NTS' strength lies in that it is based on other RFCs, such as TLS, which
are among the most carefully designed security standards in existence.
This will work to greatly improve confidence in NTS. The omission of a
description of how certificate trails are to be verified in the NTS
draft is an example of this. Certificate verification is addressed in
the referenced RFCs.

I can certainly understand the argument that an NTS standard should
provide instructions for security in other NTP modes than client/server.
If this is a concern for the group, it should be addressed in the draft
at hand. Including support for symmetric modes should be quite easy,
while securing broadcast mode might be harder.

In any case, relatively minor objections to a draft is not a reason to
throw several years' work overboard and start anew.

Kind regards,
Marcus Dansarie