Skip to main content

Last Call Review of draft-ietf-ntp-bcp-07
review-ietf-ntp-bcp-07-secdir-lc-kelly-2018-10-18-00

Request Review of draft-ietf-ntp-bcp
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-10-08
Requested 2018-09-24
Authors Denis Reilly , Harlan Stenn , Dieter Sibold
Draft last updated 2018-10-18
Completed reviews Secdir Last Call review of -07 by Scott G. Kelly (diff)
Genart Last Call review of -07 by Robert Sparks (diff)
Genart Telechat review of -10 by Robert Sparks (diff)
Assignment Reviewer Scott G. Kelly
State Completed
Review review-ietf-ntp-bcp-07-secdir-lc-kelly-2018-10-18
Reviewed revision 07 (document currently at 13)
Result Has Nits
Completed 2018-10-18
review-ietf-ntp-bcp-07-secdir-lc-kelly-2018-10-18-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

The summary of the review is Ready with nits.

This review is a few days late, I hope it is is still useful.

This document describes best current practices for Network Time Protocol (NTP).

Section 5 describes available NTP security mechanisms, and then section 6
describes "NTP Security Best Practices". I went back and forth several times,
confused by the fact that section 5 includes recommendations as well as brief
descriptions of the mechanisms. I think giving a separate overview of the
existing security mechanisms is a good idea, but I'd suggest using this section
for defining what's available, and moving the recommendations into new
subsections of section 6.

The current draft says,

   ... The calculation of
   the MAC may always be based on an MD5 hash, and an AES-128-CMAC hash
   is expected to soon be allowed as well.  If the NTP daemon is built
   against an OpenSSL library, NTP can also base the calculation of the
   MAC upon any other digest algorithm supported by each side's OpenSSL
   library.

Shouldn't this doc be recommending use of something stronger than the
(non-HMAC) MD5 hash-based solutions given that stronger solutions are
available? If both sides can choose from whatever is supported by OpenSSL, then
HMAC and/or CMAC algorithms seem like much better choices.