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 rev. no specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-10-08
Requested 2018-09-24
Draft last updated 2018-10-18
Completed reviews Secdir Last Call review of -07 by Scott Kelly (diff)
Genart Last Call review of -07 by Robert Sparks (diff)
Genart Telechat review of -10 by Robert Sparks (diff)
Assignment Reviewer Scott Kelly
State Completed
Review review-ietf-ntp-bcp-07-secdir-lc-kelly-2018-10-18
Reviewed rev. 07 (document currently at 13)
Review result Has Nits
Review completed: 2018-10-18

Review
review-ietf-ntp-bcp-07-secdir-lc-kelly-2018-10-18

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.