Subject: [Ntp] Benjamin Kaduk's No Objection on draft-ietf-ntp-mac-05: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 19 Nov 2018 10:41:19 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ntp-mac-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ntp-mac/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please consider using the RFC 8174 version of the BCP14 boilerplate.

It's somewhat surprising to me that this document seems to focus on the
"md5 is broken" aspect of the previous ntp-md5 construction, with no
mention that there is additionally a cryptographic flaw: it is subject to
length-extension attacks.  (I'm told that no practical attacks of this
nature are known, but it still seems prudent to note the additional flaw in
the mechanism being replaced.)

Similarly, to avoid concerns about the risk of extension attacks with the
new construction, it may be worth explicitly noting that the CMAC
construction is secure even in the presence of variable length messages
(see, e.g., [OMAC1a] from RFC 4493).  (In other contexts the message length
is explicitly included as an input to the MAC, though given the above that
does not seem necessary here.)

Section 3

   If authentication is implemented, then AES-CMAC as specified in RFC

Maybe "NTP authentication"?

   described in RFC 5905 [RFC5905].  The MAC key for NTP MUST be at
   least 128 bits long AES-128 key and the resulting MAC tag MUST be at
   least 128 bits long as stated in section 2.4 of RFC 4493 [RFC4493].

I'm not sure I understand why these are "at least" -- if AES-128 is used,
exact matching should be fine.