Re: [Ntp] Last Call: <draft-ietf-ntp-yang-data-model-10.txt> (A YANG Data Model for NTP) to Proposed Standardsecurity

Hal Murray <> Tue, 09 February 2021 09:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BEE53A136A; Tue, 9 Feb 2021 01:35:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.037
X-Spam-Level: *
X-Spam-Status: No, score=1.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, PDS_RDNS_DYNAMIC_FP=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cmN1IaTYffYC; Tue, 9 Feb 2021 01:34:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8FA163A1369; Tue, 9 Feb 2021 01:34:58 -0800 (PST)
Received: from shuksan (localhost []) by (Postfix) with ESMTP id E11F8406061; Tue, 9 Feb 2021 01:34:46 -0800 (PST)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: tom petch <>
From: Hal Murray <>
In-Reply-To: Message from tom petch <> of "Mon, 08 Feb 2021 11:37:09 GMT." <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 09 Feb 2021 01:34:46 -0800
Message-Id: <>
Archived-At: <>
Subject: Re: [Ntp] Last Call: <draft-ietf-ntp-yang-data-model-10.txt> (A YANG Data Model for NTP) to Proposed Standardsecurity
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Feb 2021 09:35:01 -0000 said:
> RFC8573 seems clear that MD5 must not be used to effect security for NTP  but
> this I-D imports iana-crypt-hash which allows MD5 without any  restriction,
> so is MD5 allowed or not? 

"Allowed" is the key word.  Just because somebody published an RFC doesn't 
mean that all the gear out in the field will get updated.  As Harlan pointed 
out, there is a very very long tail on NTP deployments.

I think it makes sense for iana-crypt-hash to include slots for historic 
items.  If nothing else, it is a good place to say "historic" or "deprecated" 
and give references to the details.

If you think a Yang model should discourage using MD5, then I suggest adding 
words to say that.  Better would be to phrase things so that it also includes 
other algorithms that get kicked out of the club after the RFC is published.  
I don't know of any place that publishes an up-to-date list of crypto-hashing 
algorithms and their status.


I'm looking at iana-crypt-hash@2014-08-06.yang

It says:
         id | hash function | feature
          1 | MD5           | crypt-hash-md5
          5 | SHA-256       | crypt-hash-sha-256
          6 | SHA-512       | crypt-hash-sha-512

If NTP is the only use, then I'd suggest adding a deprecated note.  But I 
assume that is used by other than NTP so that may not be appropriate.  But 
maybe if MD5 is deprecated for NTP it should be deprecated for other uses too. 

What happened to slots 2, 3, and 4?

Existing NTP code also supports SHA-1

RFC 8573 that deprecated using MD5 with NTP suggests using AES-CMAC.  Note 
that is CMAC rather than HMAC and that NTP uses it's own scheme rather than 
HMAC as described in RFC 6151.

The NTPsec code supports any hash (or CMAC) algorithm that the underlying 
library from OpenSSL supports.

These are my opinions.  I hate spam.