[Ntp] Benjamin Kaduk's No Objection on draft-ietf-ntp-mac-05: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Mon, 19 November 2018 18:41 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: ntp@ietf.org
Delivered-To: ntp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC6B130DF6; Mon, 19 Nov 2018 10:41:19 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ntp-mac@ietf.org, Karen O'Donoghue <odonoghue@isoc.org>, ntp-chairs@ietf.org, odonoghue@isoc.org, ntp@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.88.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154265287905.5256.13870177031396760992.idtracker@ietfa.amsl.com>
Date: Mon, 19 Nov 2018 10:41:19 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/Y8EhVf7bwDl38MKk3Wx-rZWgR8Y>
X-Mailman-Approved-At: Tue, 20 Nov 2018 08:12:39 -0800
Subject: [Ntp] Benjamin Kaduk's No Objection on draft-ietf-ntp-mac-05: (with COMMENT)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Nov 2018 18:41:19 -0000
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.
- [Ntp] Benjamin Kaduk's No Objection on draft-ietf… Benjamin Kaduk
- Re: [Ntp] Benjamin Kaduk's No Objection on draft-… Aanchal Malhotra
- Re: [Ntp] Benjamin Kaduk's No Objection on draft-… Eric Rescorla