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 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-10-08
Requested 2018-09-24
Other Reviews Genart Last Call review of -07 by Robert Sparks (diff)
Genart Telechat review of -10 by Robert Sparks (diff)
Review State Completed
Reviewer Scott Kelly
Review review-ietf-ntp-bcp-07-secdir-lc-kelly-2018-10-18
Posted at https://mailarchive.ietf.org/arch/msg/secdir/_7CZBW1v8o_3R3vRn-LD9R82JfE
Reviewed rev. 07 (document currently at 12)
Review result Has Nits
Draft last updated 2018-10-18
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.