Re: [Ntp] Benjamin Kaduk's Discuss on draft-ietf-ntp-bcp-10: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Fri, 18 January 2019 01:29 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E989131065; Thu, 17 Jan 2019 17:29:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.69
X-Spam-Level:
X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=mit.edu
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 1YVjtkbctf_y; Thu, 17 Jan 2019 17:29:21 -0800 (PST)
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720099.outbound.protection.outlook.com [40.107.72.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB53130F2F; Thu, 17 Jan 2019 17:29:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YnJatO5zuvWHeuYPpvnPBVJPvNBYx9O/L6jQlG1H1xY=; b=tXlS8xRDilkyuoXklTpy1/JZnAvqkVFaOIvKh2JAo9sz/L2hToEHx88FxRg/dgdhO4CJQhJWU/DOcXbUKzOku1oDIrhbqjPsn1mA79IncJGYAefnB/xQs+r1lHiMUaarA77ded6cb0FY0GTHFEOdppqUz8KLZfcFEyHVsJySerM=
Received: from CY4PR0101CA0015.prod.exchangelabs.com (2603:10b6:910:3c::28) by BYAPR01MB5526.prod.exchangelabs.com (2603:10b6:a03:123::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.27; Fri, 18 Jan 2019 01:29:18 +0000
Received: from CO1NAM03FT044.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::203) by CY4PR0101CA0015.outlook.office365.com (2603:10b6:910:3c::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1537.26 via Frontend Transport; Fri, 18 Jan 2019 01:29:18 +0000
Received-SPF: Pass (protection.outlook.com: domain of mit.edu designates 18.9.28.11 as permitted sender) receiver=protection.outlook.com; client-ip=18.9.28.11; helo=outgoing.mit.edu;
Received: from outgoing.mit.edu (18.9.28.11) by CO1NAM03FT044.mail.protection.outlook.com (10.152.81.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1471.13 via Frontend Transport; Fri, 18 Jan 2019 01:29:17 +0000
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x0I1TDW3009507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Jan 2019 20:29:15 -0500
Date: Thu, 17 Jan 2019 19:29:12 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Denis Reilly <denis.reilly@orolia.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-ntp-bcp@ietf.org" <draft-ietf-ntp-bcp@ietf.org>, Karen O'Donoghue <odonoghue@isoc.org>, "ntp-chairs@ietf.org" <ntp-chairs@ietf.org>, "ntp@ietf.org" <ntp@ietf.org>
Message-ID: <20190118012912.GD81907@kduck.mit.edu>
References: <154527086543.2219.6748696381274841433.idtracker@ietfa.amsl.com> <AM0PR0602MB37302EEA1FF4A75A9C05DB28FF830@AM0PR0602MB3730.eurprd06.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <AM0PR0602MB37302EEA1FF4A75A9C05DB28FF830@AM0PR0602MB3730.eurprd06.prod.outlook.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.9.28.11; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(346002)(136003)(39860400002)(376002)(2980300002)(13464003)(189003)(51914003)(199004)(50466002)(53416004)(47776003)(476003)(246002)(229853002)(305945005)(126002)(33656002)(486006)(75432002)(6246003)(956004)(106466001)(336012)(55016002)(4326008)(1076003)(426003)(446003)(11346002)(54906003)(58126008)(36906005)(356004)(6346003)(786003)(8936002)(26826003)(88552002)(76176011)(2906002)(316002)(7696005)(508600001)(2870700001)(6916009)(5660300001)(8676002)(14444005)(104016004)(30864003)(5024004)(106002)(186003)(26005)(23756003)(86362001)(6666004)(53546011)(18370500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR01MB5526; H:outgoing.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-auth-1.mit.edu; MX:1; A:1;
X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT044; 1:haRAQPS/cOkgk30ONccT86M7CaTeAljwp2HIUQI1MINPhKEmBoDKg7HZS5cSPTCDgrOWafT/EtXifTVrY62MXKEW8XXIUoj3p88QQZ+TSGDuL3zWEzk38E3z/S0+VNN8
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: e5b7e6c6-7903-4105-89c1-08d67ce45d92
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4608076)(4709027)(2017052603328)(7153060); SRVR:BYAPR01MB5526;
X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB5526; 3:H2aSMW0Fo/uij1j/uYDnnbx64ii3GzCrHbfq3ODyAFKNzSGM58weamWjPuvw2BkJDiucjoqCxmWFS+h69KAGUuIRGGE3+DYewJOZ1+KuTFpNLHrom0IF9LnzyLqiqC2rJeinqe///XMhSiWiwcbMvDL+PVwv/SeYERVCGIw4XITPp0jwHmyYZopg67rHaufvBpCRoW/YJVk2b+4x/f86i43fE8+m9jivk1+3FXzwnu/f6ocLQrmX9uERdhbjI59Dhl+Ls9YuneEv4tftnHHXqYiCxVuDzodR+W5rYvip35EEXWZtfQpSw7liPEnaZJ8RZ3se5gZEuIJp/q1YTEVqUjDKEz6JVksYcXlQ5knDZ2MU9rJ0LaZeJdKbHX8F/4lh; 25:mOQzaf92GPpvcvxIhUJqD6y7NfNdEyGAYbbSOy6Z0lzu9tihxYZNAKHHxcJSH8b+5EPmUxNh0t2D2Cc2NJYx8/cLEqdcLbvTz4DsBmC806Lob+JREPiudXxngznORnpD7ICpBR4KnsgOKCLpkvWPoHtMyaRLZrXlVX+yFjhU2o7ZOfNN1KnmBnc/VUUlQwzSuoc6X4dX9hktT3vOdNC/2da4n5ALv9uLUVDdyhnSMWX9LmmQaP0WK/3ml2tWUN1rpCAuvnodJ/Ayhtj9IZxvMkA6PqlP1C+QQPRIS8NYbdCtBvTLDGTvpjcIq6EuOMaPdR9l6nXZaf9HPtcjeBoAMg==
X-MS-TrafficTypeDiagnostic: BYAPR01MB5526:
X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB5526; 31:otwPye2JDeQhEXUnXElE8l3MTQqzTYoaJtOC/rBqlDJwcoqkZRb2cGwTxxaXj9wKqvOwUwf/aMH3cEghRsWSwZEH/lzgKEj72apVCeiracWw3/H1gM9Lg08WPJ5/d47/k6RaQ4bfY+fvSiCg2DtvF9dzTB0m27VfcW4MTN53YYukQhawLY2zLVPEEDGZnYgxXoogJdTcV9n5WcUiH7BOYtP6LXFqEMNNpG+S0Rb8Wew=; 20:ApGZIVO8C5ZRmsKduwSvPQQJZBrjxDASs/HoQ1vRJJiaD9VUivw5xnTsiCraoHjoiVjfz5/JihOH4myLB/ylEpxu5NWO9FDoIFi048XqsdufPYPGsJtURewEhkmv+vN3PTSiXADB/kUanLipkFImX0XBwDCMGvb63VfizGZz43nuPnm9NqEOqDgkj1xJwFPILbLBCW+aLzioETz8jNnpzKJyEegqrcJHI/5pBOaj9ij2seO6Jok1Nbo3ueojSXGi3Ytk/Qi351VwxCDIvEGpbs3TlHY+9GSem3Ec1W6Mb3sztAxkPgC2vIDT/d1/fuBTLuT9ELGfquxzAGS497ibGXpyC8i0k6yv5IvnvSnAoiRhofFTAX4EWjCrE+tBB4E9aZgkysKiO1dauTVSby4eJXZByC1qUVMUhAr3MZgEx/UCm8ZuT6rd5kVEwsneS5pYSjlXH5oB8Bxr6K/2gdetqJ5f1rWa8JBGVCg3ECBRODpcNiyDBHykGpkVPDnSaSGrj1ny+fna5mGrwN0LW0Q2ZlcN28qZXFu+kWttPI7uZmpzLqifchuIR2cfMlKkM2P2rfen0ZpS54mIYwhy4CDn92deoV3IGkN9Fky1wgUgQ2s=
X-Microsoft-Antispam-PRVS: <BYAPR01MB55264EF3288977E242FCF311A09C0@BYAPR01MB5526.prod.exchangelabs.com>
X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB5526; 4:VDitJ8UvOt512yz1NzMAkUBdi2idR1L+yUF9ai3UrXc7QpJnfBABrgPio8uFq8b7gE4O9Ynhcpv8bx+VLO5oBvotU4Rr5a6JKesEaaEIgUW18On5iffEFVUb0tdfQqMnc7EcZjMZvxfetFkqUhauYk/moUx+FKY9OALs8moezNoEPwSq00ieWZ0xxXaW5Y/W5ZXDFv0vF5MbiYajdW2Qei9bKoxqfDGBj8jUcf/5+wyH0kF3gkRFUrM6SsD1bgRzPRjBOFBW0PaQIhsroxythgMa/R6DJx/RxNfWWZZPjgPKcC0tSZrw7SYCZ7g8IY67
X-Forefront-PRVS: 0921D55E4F
X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB5526; 23:xWF5hzlYdiDXFwkEjhdJJOEbCNH7LYCzRnHa0tRudmJCYKCjbu9AF3F7zjNq0pxeYQ4UjY+OcUwh5A0pfCtKFpxTXEEjqfcOMzIP0qZPLit8c19eMDZykklE7udo1TUUiWGOKEzxVPHcfJ1ohLM0KodpJYvFBq3XegSzykoCYCoI3TpP6r9KRMk901G4oEnferwKJnmaw8YfUI1tbxfF6bq2R8EfC8gt7DUPKRgk/YifGRG3lMbI4F7zKy+8azJJiweotId3n7mzKGcrwZMvg5krG4+8Btzqfhk17vilgbqS+5D80qXUjETOE7LZZAmh6Xj6MqyW3MLhOrOYi3D8sY91e6vP2X7RLwqMy70EN0Yvu73YSY1tIkmmFrTL1M/Cn8SV5eAFd8n5mxWHbKa6Wks32sPcq6jPrTnr8Uyz8dxnlA1kHCfJqaMi5fDVisYEVkSLJ9Rh6yPh9Gb1bghJp9Gk1I9WzsglJosXJyv2c8gJ2y/b/3jHTvdlVZtE82gbjJv6Ww1kYxQIgvL77bAnCDhWKv75dGjdkFSXBXnDXQnDtg2JNyMkrzYK9ps1kbhGak05mT1DeKvMA85gyAwEejfNJb/q6SGCUyUt+Ptwgd6ldxsHw/nAsGOmLQdPWhdAf+4McdvgWG00o+2v673SMSPh6dQ4LaJeIZFfpJdTZsR2LC9xFXvKvYbOvGbX75GRtqQZdXght704VEqiMTZhgVx/GmfRNqGHXqax7a21QGsgp8BvU8a0IbrbPNFbqQS20hrOONiUhEwZYAhawIlY4VPofYGbkvyTYQDkjKCSJN73ve4H6wFUdP5sT620L6DPkI8XucmBSLDDumWC4oNVZTWHQOvkkedXpILSqaASSvx+ysJ3mM/U2JecF154Pk8qDNPj6LpyvvI1pVinXVLAGfHcK+iSjp0M2hoXo5o5p85tqtvnkhmQU0FUD7kV3Zuk+Cr49iJqZAlnBj/beyTqB4rJsdgZ2+oVijSCfJX46A/Z+zttjyKjILqSLz2Am/XrW+nc0DDQb+kavI/bJSGtYM1hRGUGS6/KcJaJwRHk6jdS6zQQVYTSTYjjD7Kvviug9OdrGmNEJ04gdKFV5ffi79h6kvcQTjRgQFXSK/JrXcyYF6b6fKNT/zYNFxnPBy7WYnvwU+szfPek9YVH8NYmRjIaFN5oAbfNPi1lryJRlDhpuzb6yL2dcCglx3T/E96xepcpOR/sMUtIpOyuLYv30upnNjGXuLaHBxWaXgNJF1zZB6MOR7aM9pdGms6OiMTb73oe+zxbtliZF3N1JSqg7CoJwqC9uoFphjXoirPS5ilyIm+k4D81uNdbsX5YFzP3
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: m1wdPugFrb68tgE/mx2qu/yKqkCvDj7kVrXit1a6fHVxWl2VebSS1EiwwpmMbqDZIYmN0TnnpAswVzZj+XQBMdsM2qxcI/cYhqGYorGynYLQjTiUiENVzRQ4OVNQ8lI8ypaTyEZBBhhF6Nq77XG+VmHQhglgAOYNb3iWvFJHGI9J+Km0x1d64AhKwPoi+kD+0t5Pcg6HZkwh1pvFSODPmMoqrB1DnCmtD4Anlqd5aFKsWndHF1cvJ6PZt4YJ6+GvZNVdYw2VH0cl/pTgCMs8pL+GEhaCpUHMbXw6zwuaatS/xoIK1FT/MJBtYgvjmKr2S6cHXtmGhI8+aC6iDPYVjpWsj1jw+ZSZ4mT87mtZukI9Al5dEnIaO7qKgMOAiCdyhi5gYrjkYKHEijSwNMy6Tks0W5Aj0pbaezMq/47Ux1w=
X-Microsoft-Exchange-Diagnostics: 1; BYAPR01MB5526; 6:w0Asc+/1+WFukKiD2+8fX8fDtziKanbq1y0IJPo0xFYgqAHYRG0mYc3ub3bbwqMaK8qT8Y+nvQFdKkl2m/jOP9bXetg+RSc5LUjk7B3TqGdehNEEr4qVkvFn6Nq9fHKJv5rGE2WV2byc5h0S7VVrWda6445dZGoW865uYUFb5FAxplVVVNRXQ3QqW7N9vkhH28mYA09vqfM7977zzyausCWQeSGhT0VIq3Del272iBcRFCyAi4NLgH91F7uuYJm7ATBY/AuqYAB2E83QKtV6pxXBtA25HtYN/aF+dA4ap3/8pMULUpgjQe42ZYr9AnqgHCmljmiAdGgSRDVUY1R0qfSoYTzvRPGOg+9/MD+Dhhiw5wXoPyfgJE9zdaaGYxkgc/7xQbPqBOOH/vvI5YsfI5aYJd9cz8yzrYKFc0MfYP4rS76KVsuFRrYsMVMB3LpsivcVqAxNqd4YCSz4HRz7mw==; 5:UBHcHwKUguNp0juhQoITTKO6pxO2+HAyDFx8XrSi9cwuV4wYsFhkPPbJ3CFGjPycmRDP+mAcZfKlLE/y7Jgn7z+0Mrt6Ka2ba08e2l6DNXRDN8RRE02XkK9emPokkiQiSNzBlJvAJ5GJyKI/EfPp/pJYdNsou5bKRB+mKQdrm6l98wnRQ7geDOn3mXKNX1bCpBOJpgOnVJW6Os2ObJHJxA==; 7:ujEUdFleTE6ExnlHMCyhsAg77fWdyjGBZNO+r8T3YYoAGQEuBswlSWjRzQE1+YFaR/OQ31jYShQpSL7+FO5hJZ9TkKSSVeD6KiwwH+mxoGGCneoU4d74llmOAJCvqxiSPZZIiXrRfG36G/4YaGcPzA==
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2019 01:29:17.7838 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e5b7e6c6-7903-4105-89c1-08d67ce45d92
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=64afd9ba-0ecf-4acf-bc36-935f6235ba8b; Ip=[18.9.28.11]; Helo=[outgoing.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR01MB5526
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/YoahcnLrFAfVsXWaPTW_KHULhxM>
Subject: Re: [Ntp] Benjamin Kaduk's Discuss on draft-ietf-ntp-bcp-10: (with DISCUSS and COMMENT)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Fri, 18 Jan 2019 01:29:24 -0000

On Thu, Jan 17, 2019 at 06:14:07PM +0000, Denis Reilly wrote:
> Hello, Benjamin! Thanks for the review. I've posted a new version of the draft which incorporate the feedback from the review.

Thanks for the updates; they address nearly everything and possibly
actually everything I requested; see below.

> See responses in-line:
> 
> --
> Denis Reilly  |  Technical Lead  |  denis.reilly@orolia.com  (585)321-5837
> 
> -----Original Message-----
> From: Benjamin Kaduk <kaduk@mit.edu> 
> Sent: Wednesday, December 19, 2018 8:54 PM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-ntp-bcp@ietf.org; Karen O'Donoghue <odonoghue@isoc.org>; ntp-chairs@ietf.org; odonoghue@isoc.org; ntp@ietf.org
> Subject: Benjamin Kaduk's Discuss on draft-ietf-ntp-bcp-10: (with DISCUSS and COMMENT)
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I see that Ben has already asked about the SHOULDs (vs. MUSTS) for secure key exchange and prevention from disclosure, in Section 4.1, but I will make that a Discuss point.  If these are to remain SHOULD, we should say something about in what case(s) MUST would not be appropriate.
> 
> I'm also concerned that there is too much intermingling of general BCP-worthy advice with implementation-specific knowledge for publication as BCP in the current form.  I've tried to note instances of this in the comment section, but for example this includes talking about the "key file"
> and the format of the configuration file.  In a similar vein, it's unclear that the guidance in Appendix A will age well, at least without a more explicit disclaimer (including disclaimer of normativity) -- e.g,. are the
> -4 and -6 modifiers to restrict still needed or best practice?  IIRC a recent update on my FreeBSD machine updated ntp.conf to just use basic restrict stanzas without an IP version.
> 
> I'm also surprised to see no discussion of the (non-)applicability of IPsec for NTP traffic, when authenticity or access control is required.  (E.g., where IP acls are discussed in Section 5.1)
> 
> Response:
> Regarding the key exchange: 
> Our original motivation for keeping these as "SHOULD" was that there was no formal recommendation we could point users to on how to secure these keys,. (Alissa Cooper had already brought this up as a Comment.) But we have received enough feedback from the reviewers here that we will change these to "MUST"s.
> 
> Regarding the Key File:
> We will refer to the key file as "local key storage" in the body of the document, to make it a bit more generic. We keep the reference to the key file in the ntpd-specific appendix.
> 
> Regarding the Appendix:
> I admit that we don't quite understand what sort of disclaimer you would like for the appendix. Aren't the appendixes already non-normative?

Appendices are not inherently non-normative; RFC 8446 is a handy example.
The case here is particularly unclear, since Section 3 explicitly says
"Best Practices that are specific to the Network Time Foundation
implementation are compiled in Appendix A", which is fairly easy to read as
including the appendix by reference.  My understanding (which could be
wrong!) is that a more accurate description would be something like
"Application of these best practices that are specific to the Network Time
Foundation implementation, including example configuration directives valid
at the time of this writing, are compiled in Appendix A."

I've cleared my Discuss in the datatracker, since it seems like we will
easily be able to adjust the text here to match the result of our
continuing discussion, if needed.

> Regarding IPSec: 
> We will add an additional sub-section for "External Security Protocols":
> 
>    If applicable, external security Protocols such as IPsec and MACsec
>    can be applied to enhance integrity and authenticity protection of
>    NTP time synchronization packets.  Usage of such external security
>    protocols can decrease time synchronization performance [RFC7384].
>    Therefore, operators are advised to carefully evaluate if the
>    decreased time synchronization performance meets their specific
>    timing requirements.

That is exactly what I was looking for; thank you!

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> In general the writing could be tightened up some more, especially to remove duplication and improve transitions.  I've noted several instances in the comments (mostly tagged with "nit"), as well as some more substantive comments.
> 
> Section 2.1
> 
>                    UDP-based protocols such as NTP are generally more
>    susceptible to spoofing attacks then other connection-oriented
>    protocols.  [...]
> 
> nit: was this intended to be "other, connection-oriented, protocols"?
> 
> Response:
> "UDP-based protocols such as NTP are generally more
>         susceptible to spoofing attacks than connection-oriented
>         protocols."

Better than my suggested text; thanks.

> --
> 
>                NTP control messages can generate a lot of data in
>    response to a small query, which makes it more attractive as a vector
>    for distributed denial-of-service attacks.  [...]
> 
> nit: more attractive than what?  (I.e., maybe just "makes it attractive")
> 
> Response: We agree
> 
> --
> 
>    BCP 38 [RFC2827] was approved in 2000 to address this.  [...]
> 
> nit: maybe, "BCP 38 was published in 2000 to provide some level of remediation against address-spoofing attacks"?
> 
> Response: We agree
> 
> --
> 
>                                                It is RECOMMENDED that
>    large corporate networks (and ISP's of any size) implement ingress
>    and egress filtering.  More information is available at the BCP38
>    Info Web page [BCP38INFO] .
> 
> BCP 38 already makes this recommendation, and the current document is supposedly scoped to just NTP, so I would have expected wording more like "It is recommended that [...] that use NTP implement ingress and egress filtering.", if we can even be clear about who this directive is supposed to apply to.
> 
> 
> Response:
> Personally, I (Denis) like the broader recommendation here, as it seems like a good idea to emphasize the importance of the BCP. But we can move the sentence "Mitigating source address spoofing attacks should be a priority of anyone administering NTP." to appear at the start of the next paragraph. This will better clarify why the recommendation is there.

It does help clarify, thanks.

> --
> 
> Section 3.1
> 
>    Many network security mechanisms rely on time as part of their
>    operation.  If attackers can spoof the time, they may be able to
>    bypass or neutralize other security elements.  For example, incorrect
>    time can disrupt the ability to reconcile logfile entries on the
>    affected system with events on other systems.  An application which
>    is secure today could be insecure tomorrow once an unknown bug (or a
>    known behavior) is exploited in the right way.  Even our definition
>    of what is secure has evolved over the years, so code which was
>    considered secure when it was written may turn out to be insecure
>    after some time.
> 
> The first three sentences seem related, but the last two sentences seem to be talking about something qualitatively different (namely, "more vulnerabilities being discovered over time", compared to the original's "accurate time is important for secure and correct operation").  I would suggest a paragraph break and some transitional language.
> 
> Response:
> We've removed those last two sentences in the latest draft, because we now feel the first three stand on their own.

That seems like a fine resolution to my point, though I see in the -11 that
the entire paragraph has been removed and not just the last two sentences.
Was this the intended change (e.g., based on other review comments)?

> --
> 
> Section 3.2
> 
>    But even with 4 or more sources of time, systemic problems can
>    happen.  For several hours before and after the June 2015 leap
>    second, several operators implemented leap smearing while others did
>    not, and many NTP end nodes could not determine an accurate time
>    source because 2 of their 4 sources of time gave them consistent UTC/
>    POSIX time, while the other 2 gave them consistent leap-smeared time.
>    See Section 3.7.1 for more information.
> 
>    Operators SHOULD monitor all of the time sources that are in use.  If
>    time sources do not generally agree, find out the cause and either
>    correct the problems or stop using defective servers.  See
>    Section 3.5 for more information.
> 
> nit: the transition here is a bit odd.  I would suggest either introducing leap second smearing as a separate concept first (e.g., by forward-reference to Section 3.7), or making the second quoted paragraph mention that leap second smearing is one of many potential causes for disagreement amongst time sources.
> 
> Response:
> We rewrote that first paragraph to make it flow a bit better:
>     But even with 4 or more sources of time, systemic problems can
> 	happen. One example involves the leap smearing concept detailed in 
> 	Section 3.7. For several hours before and after the 
> 	June 2015 leap second, several operators configured their NTP servers 
> 	with leap smearing while others did not. Many NTP end
> 	nodes could not determine an accurate time source because 2 of their
> 	4 sources of time gave them consistent UTC/POSIX time, while the
> 	other 2 gave them consistent leap-smeared time. This is just one of 
> 	many potential causes of disagreement among time sources.

The forward reference to 3.7.1 helps a lot; thank you!

> --
> 
> Section 3.3
> 
> nit: the Q&A style in the second paragraph is not something I usually expect to read in a BCP.
> 
> Response:
> Maybe it's just a reflection of our writing style, but these do reflect
> questions that we think operators should ask when determining whether their 
> implementations are diverse enough.
> 
> --
> 
> Section 3.4
> 
>                              Used improperly, these facilities can be an
>    abuse vector.  [...]
> 
> I think (but am not 100% sure) that it's an attack vector on the server itself, as well as an abuse vector.
> 
> Response:
> We've changed this to "But these facilities can be a vector for amplification attacks when abused."
> 
> --
> 
> Section 3.4
> 
> The BCP 38 recommendation was already made above; do we really need to duplicate it here?
> 
> Response:
> I (Denis) think it's important to link the two, as this shows additional rationale for implementing BCP38. But we do mention NTP Control messages in the BCP38 section; maybe it's better to just reference that section so we don't repeat the recommendation.
> 
> --
> 
> Section 3.5
> 
>    If a system starts getting unexpected time replies from its time
>    servers, that can be an indication that the IP address of the system
>    is being forged in requests to its time server.  The goal of this
>    attack is to convince the time server to stop serving time to the
>    system whose address is being forged.
> 
> nit: the writing here could probably be tightened up.  E.g., things like "NTP reply packets that do not correspond requests it sent", "an attacker is forging its IP address in requests to the time server", and "one reason an attacker would do so could be to convince the time server to".
> 
> Response:
> Changed to
> I
> f a system starts to recieve NTP Reply packets from a time server
> that do not correspond to any requests sent by the system, that can be
> an indication that an attacker is forging that system's IP address in
> requests to the remote time server. The goal of this attack would be to
> convince the time server to stop serving time to the
> system whose address is being forged.
> 
> --
> 
>    If a server's system log shows messages that indicates it is
>    receiving timestamps that are earlier than the current system time,
>    then either the system clock is unusually fast or somebody is trying
>    to launch a replay attack against that server.
> 
> Is "receiving timestamps" supposed to be for NTP messages in particular, or all general syslog traffic?
> 
> Response:
> We are referring to NTP timestamps, and will clarify this in the next draft.
> 
> --
> 
> Section 4.1
> 
>    [RFC5905] specifies a hash which must be supported for calculation of
>    the MAC, but other algorithms may be supported as well.  The MD5 hash
>    is now considered to be too weak.  [...]
> 
> nit: "too weak" for what?  (Maybe "considered to be weak and unsuitable for cryptographic usage" would be better, with a reference to RFC 6151 or similar.
> 
> Response:
> We are adding:
> The MD5 hash is now considered to be too weak and unsuitable for cryptographic
> usage.  [RFC6151] has more information on the algorithm's weaknesses.
> 
> --
> 
> 
>    To use this approach the communication partners have to exchange the
>    key, which consists of a keyid with a value between 1 and 65534,
>    inclusive, and a label which indicates the chosen digest algorithm.
> 
> Surely there is also the actual cryptographic key material itself!
> 
>    Each communication partner adds this information to its own key file.
> 
> Does the reader know what a "key file" is at this point in the document?
> (Alternately, is "key file" an implementation detail and not a protocol
> concept?)
> 
> Response:
> We've replaced "key file" with "local key storage" in the body of the document, and put more specific information about where to insert the key into the ntpd-specific appendix (where it is more appropriate).
> 
> --
> 
>    Some implementations store the key in clear text.  Therefore it
>    SHOULD only be readable by the NTP process.  Different keys are added
>    line by line to the key file.
> 
> Similarly here; the "key file" is only vaguely and implicitly described (and the line-by-line format is clearly implementation-specific); the main actionable point here is just to ensure that it is only readable to the NTP process and the rest could, I think, be safely omitted.
> 
> Response:
> We'll omit the last sentence.
> 
> --
> 
>    An NTP client establishes a protected association by appending the
>    key to the server statement in its configuration file.  Note that the
>    NTP process has to trust the applied key.
> 
> If the configuration file format is not standardized, there's not much useful for us to say here about its contents.  Also, what does "has to trust" mean?
> 
> Response:
> We can rewrite to be clearer:
> 
> An NTP client has to be able to link a key to a particular server
> in order to establish a protected association. This linkage is
> implementation specific. Once applied, a key will be trusted until
> the link is removed.

Looks good.

> --
> 
> Section 4.2
> 
> The reference is provided only for the attack on autokey but not for autokey itself.  Is there a stable reference for the autokey protocol (so that people know what to not use)?
> 
> Response:
> We've added RFC5906 as an informative reference.
> 
> --
> 
> Section 5.1
> 
>                                                          NTP control
>    queries also leak important information (including reference ID,
>    expected origin timestamp, etc.) that may be used in attacks
>    [CVE-2015-8139].  A remote attacker can learn this information by
>    sending control queries to a target system and inspecting the
>    response.
> 
> Er, so is it the control *query* that leaks information, or the response to that query?
> 
> Response:
> We can clarify this by changing to "and inspecting the leaked information in the response."
> 
> --
> 
>            It is recommended that operators SHOULD filter mode 3 queries
>    at the edge, or make sure mode 3 queries are allowed only from
>    trusted systems or networks.
> 
> nit: "at the edge" is not a well-defined concept here.
> 
> Response:
> Will change to "from outside their networks".
> 
> --
> 
>    Note well that proper monitoring of an NTP server instance includes
>    checking the time of that NTP server instance.
> 
> Perhaps more explicitly state that the above recommendations for leaf hosts preclude such monitoring [of leaf hosts]?
> 
> Response:
> Will change to "An exception to this can be made if a leaf-node host is being actively monitored, in which case incoming packets from the monitoring server can be allowed."
> 
> --
> 
> Section 5.3
> 
> Do we want to say anything about what to do when a (potential) attack is detected (e.g., make an entry in the system log)?
> 
> Response:
> We don't think so, because the monitoring in this section may not be done
> by the NTP implementation itself. If an operator uses an external tool to performance this monitoring, we don't want to impose any requirements on that.
> 
> --
> 
> Section 5.4
> 
> It seems worth reiterating that these KoD packets will be accepted in common usage even when not cryptographically authenticated, which makes the DoS risk more severe.
> 
> I am not sure whether the note about KoD packets indicating potential attacks is better here or in the previous subsection.
> 
> Response:
> We want to keep the note here, but we've added your suggested text:
>    Kiss-o'-Death (KoD) packets can be used in denial of service
>    attacks.  Thus, the observation of even just one KoD packet with a
>    high poll value could be sign that the client is under attack. 
>    And KoD packets are commonly accepted even when not cryptographically 
>    authenticated, which increases the risk of denial of service attacks.
> 
> --
> 
> Section 6.1
> 
> This is entirely editorial (and thus your preferences outweigh mine), but if I were writing this I would say something like "an up-to-date and secure NTP implementation" rather than "the latest NTP updates applied".
> 
> Response: We Agree.
> 
> --
> 
> Section 7
> 
> Would it ever make sense to have multiple (disjoint?) anycast pools so that clients could still benefit from having multiple servers concurrently available to compare?
> 
> Response: A good point, we will add it.

Ah, thank you.  (I was not entirely sure whether it would make sense or
not, so I appreciate you taking the time to think about it.)

Thanks again for all the updates; they add up to a much tighter document!

-Benjamin

> --
> 
> Appendix A.*
> 
> It would be helpful to distinguish which strings are literal syntax that must be used unchanged and which strings are supposed to be user-replaceable.
> 
> Response: We've changed the text of the Appendix to make this more clearer, mainly in the Prre-Shared Key section.
> 
> --
> 
> ATTENTION: This email came from an external source.
> Do not open attachments or click on links from unknown senders or unexpected emails.