[secdir] secdir review of draft-ietf-ntp-bcp-07

"Scott G. Kelly" <scott@hyperthought.com> Fri, 12 October 2018 21:12 UTC

Return-Path: <scott@hyperthought.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1CB124BE5 for <secdir@ietfa.amsl.com>; Fri, 12 Oct 2018 14:12:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfV-L-laA799 for <secdir@ietfa.amsl.com>; Fri, 12 Oct 2018 14:12:49 -0700 (PDT)
Received: from smtp90.iad3a.emailsrvr.com (smtp90.iad3a.emailsrvr.com [173.203.187.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67187126DBF for <secdir@ietf.org>; Fri, 12 Oct 2018 14:12:49 -0700 (PDT)
Received: from smtp36.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp36.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 4D875551C; Fri, 12 Oct 2018 17:12:48 -0400 (EDT)
Received: from app15.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp36.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3896554A8; Fri, 12 Oct 2018 17:12:48 -0400 (EDT)
X-Sender-Id: scott@hyperthought.com
Received: from app15.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Fri, 12 Oct 2018 17:12:48 -0400
Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app15.wa-webapps.iad3a (Postfix) with ESMTP id 26942A0F21; Fri, 12 Oct 2018 17:12:48 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Fri, 12 Oct 2018 14:12:48 -0700 (PDT)
X-Auth-ID: scott@hyperthought.com
Date: Fri, 12 Oct 2018 14:12:48 -0700
From: "Scott G. Kelly" <scott@hyperthought.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-ntp-bcp.all@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
Message-ID: <1539378768.15629707@apps.rackspace.com>
X-Mailer: webmail/15.4.3-RC
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/_7CZBW1v8o_3R3vRn-LD9R82JfE>
Subject: [secdir] secdir review of draft-ietf-ntp-bcp-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Oct 2018 21:12:51 -0000

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.