Subject: [Ntp] Fwd: Comments on last call for draft-ietf-ntp-using-nts-for-ntp-14

From: Watson Ladd <[email-masked]>
Date: Fri, 9 Nov 2018 21:01:04 -0800

Dear all,

Below are some comments on the draft. I've been asked by Nick Sullivan
to take a look with an eye towards implementability, and am not that
familiar with the conversations that have taken place before, which is
perhaps in some ways an advantage and in others a definite
disadvantage.

The first comment is the string TBD appears a few times in the draft.

The second is that the costs of asymmetric crypto are not that much,
and shouldn't interfere with handling time packets in an quick manner,
especially if the time server and key negotiating server are distinct,
which this protocol supports.

I am unsure the port negotiation option will see much use. Also why
are clients not required to implement AES-SIV to ensure an
interoperability baseline?

Otherwise it seems good to me, and I think it will be fairly quick to
implement.

Sincerely,
Watson Ladd

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Dieter Sibold" <[email-masked]>
Date: Sat, 10 Nov 2018 18:22:22 +0100

Hello Watson,
thanks for your review and comments. See my replies inline.
- Dieter

> The first comment is the string TBD appears a few times in the draft.

Yes, but expect for one all others require allocations by IANA. We will 
correct this accordingly.

> which this protocol supports.

I don’t agree at that point. NTS by design provides no means to 
correct for the delays introduced when client and server generate the 
AEAD tag, respectively. These delays increase the uncertainty in the 
calculation of the time offset between client and server. Symmetric 
crypto is in my opinion therefore the most natural choice in order to 
keep these delays and the error in the time offset calculation 
associated with these delays small.

> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Marcus Dansarie <[email-masked]>
Date: Mon, 12 Nov 2018 19:27:38 +0100

Thank you for your comments on the draft! I've addressed a few of your
points below.

> which this protocol supports.

I'd like to add to what Dieter has already said here by pointing out
that there are NTP server implementations (e.g. www.ntp.se) that can
reply to tens of gigabits of NTP queries every second. Enabling NTS on
those implementations will not be possible with asymmetric crypto, which
is orders of magnitude slower than symmetric.

> interoperability baseline?
You are probably right about the port option (section 4.1.8). That is
why it is optional for the NTS-KE server to honor it. It's main purpose
is to enable the use of NTS on NTP servers that use non-standard ports
(i.e. not port 123). This is necessary if one wants to run an NTP server
without root privileges on a Unix system, for example. As a consequence,
there needs to exist a way for the NTS client to unambiguously request
cookies for a server that uses a non-standard port.

When it comes to clients not being required to implement AES-SIV
(section 4.1.5), I consider this a feature. The interoperability
baseline is established by requiring NTS-KE servers to support
AEAD_AES_SIV_CMAC_256. Clients that require the use of another AEAD
suite may choose to include only that negotiation record in their
request, knowing that this could cause the key exchange to fail. If they
prefer another suite but still consider AES-SIV acceptable, including an
AES-SIV record with lesser preference guarantees that the AEAD
negotiation will succeed. It does not, however, guarantee that the
server will use their most preferred suite, even if it supports it.

Kind regards,
Marcus