Re: [secdir] [Ntp] Secdir last call review of draft-ietf-ntp-mode-6-cmds-08
Harlan Stenn <stenn@nwtime.org> Sun, 14 June 2020 20:46 UTC
Return-Path: <stenn@nwtime.org>
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 3ECBC3A128A; Sun, 14 Jun 2020 13:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=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 WnXzzvNPCkL2; Sun, 14 Jun 2020 13:46:46 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (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 BB8013A1230; Sun, 14 Jun 2020 13:46:46 -0700 (PDT)
Received: from [10.208.75.157] (075-139-194-196.res.spectrum.com [75.139.194.196]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 49lRMp04sfzL7c; Sun, 14 Jun 2020 20:46:45 +0000 (UTC)
To: Karen O'Donoghue <kodonog@gmail.com>
Cc: Brian Haberman <brian@innovationslab.net>, Daniel Franke <dafranke@akamai.com>, secdir@ietf.org, draft-ietf-ntp-mode-6-cmds.all@ietf.org, last-call@ietf.org, ntp@ietf.org
References: <ea8aff7c-35fa-6d64-3a75-21b31b45a9d9@nwtime.org> <13D6D5C7-090A-4C68-8F0B-EA6DE18FB1E9@gmail.com>
From: Harlan Stenn <stenn@nwtime.org>
Autocrypt: addr=stenn@nwtime.org; keydata= mQGNBFI2xmQBDACrPayw18eU4pIwCvKh7k0iMkAV9cvzs49kBppM+xoH+KKj4QWmkKELD39H ngQnT3RkKsTLlwxyLqPdUmeQNAY2M5fsOK+OF6EvwLPK9hbmE3Wx2moX+sbEUxJ2VzFhKSKb OPZALXwk1XxL0qBedz0xHYcDwaSAZZkEFXURv2pDIdrmnoUnq2gdC8GpoFJiXoUaCLSYzzaY ac4Njw7Mue8IqfzRQb70aMjXl/qmsmfmEVAyGXywDdc/ler4XSgiuYOV7Kf69bj9PFZZSMdJ MWgEyZH6lJ0TU5ccR2zp5ZRmWzQQkxJMyH2th7q0Nmz3aX4A0K4yE0Ba9/5Dr7ctpF15BrMF aEo4s5lwI6tUnkgMWo265mMzCz4mAPV/ac0w0OXQg7r9E2r0+dRapnzUlG43D0JLDqDr9uRR L6IrRQqoCWUC75lfmPYQYSlaTJaK68r3lXd0z1cXJUgVtEL5H3/Z71R2B20twcQVAnw2iIH6 L5vdrsIjHrMmkqRVbs9nNyEAEQEAAbQ5SGFybGFuIFN0ZW5uIChOZXR3b3JrIFRpbWUgRm91 bmRhdGlvbikgPHN0ZW5uQG53dGltZS5vcmc+iQG5BBMBAgAjBQJSNsblAhsvBwsJCAcDAgEG FQgCCQoLBBYCAwECHgECF4AACgkQyIwAt1pH+kBlzgv/QOg70vdj8wU/z97UPdlbxtN4THAB gfSX4N0VPKT5fjX1tFhuXZQAOv7wedR3Trh7TGteyg33TBAFf9A42mXZKi1IxAiQG118Hd8I 51rXwnugURIYQaIyQI+vbchRbwVyz+mVLTI/h6FdbsVzT4UFmir+ZMkb/XeZPu0HItk4OZHE 6hk+TuTiCnlqlCPLq371fXV54VOb91WZYD8EQFtK02QHGHsQqWvapdphiDVpYehmsPyiTESq NMKLVtjtyPkQ6S7QF3slSg+2q3j8lyxEA78Yl0MSFNU8B/BtKgzWP2itBOfi+rtUKg+jOY1V /s2uVk2kq2QmHJ/s5k5ldy3qVvoTpxvwBe0+EoBocTHYt+xxp0mTM6YY1xLiQpLznzluqg9z qtejX1gZOF4mgLiBIrhXzed3zsAazhTp5rNb1kn0brZFh6JC5Wk941eilnA4LqX8AWo0lmwo eb+mpwZK/5lNdage/anpVqft9wJ/8EcvST9TLUO4fPrmT3d/0LpWuQGNBFI2xmQBDADXLsBk I7CSa5UXlrNVFJQHER1VxRBKqjWWCh/8Qv9v3p3NrIc2UnhoZ1uWQ2voBGty5Xfy9k4afV5k WwDyRDUIb7PX+Tj4HjVVr7qvnOVe/0KzZpNq0Azd0ggFbsM+8mydktHIwJykW0NUsGwPRYuD OA0Lro0ohb5IiCt3sSQi1X1hYjo7O1Vmn8Gy/XYOnhnMux+5zDPO2yTkCNX5PocYi9IJJy6p Mq1yQV4Y2Dl8KtQzvtq55vCUxx6n0MMzFViGwNW6F4ge9ItO4tDScsgowDrHa208ehwOpv/i wjf93lCClQ6vaKmOBX872K/tdY/hwhxPPjgl1bcrOwMRYVemOPPehwnXH5bwclk1hvDQdkJQ 5pJOkE4VCryTF/iDAt4g2QnHocUwt3b6/ChUUWmj2GZ22OR12rbnCtLedwp0DpViKPUCQHBO vpgXdzE/L9zWar9fqM0EREMgfWbsJc9028qluCcFLIN1gYsq4cC+YGAcOu7HOI5orBBV4m9j XfsAEQEAAYkDPgQYAQIACQUCUjbGZAIbLgGpCRDIjAC3Wkf6QMDdIAQZAQIABgUCUjbGZAAK CRDfCQ/G52/8P/uWDACe7OEM+VETDRqjQgAwzX+RjCVPvtgrqc1SExS0fV7i1mUUxr/B8io3 Y1cRHFoFKmedxf8prHZq316Md5u4egjFdTT6ZqEqkK0hvv+i0pRpCa5EX9VIStcJStomZp8F cY34grA+EOWITaLQ4qNZUP7rf2e7gq1ubQTj7uLr6HZZvMZ5em+IvrOWEuWDI6yOiI6px04w RDfkoR2h6kgdw4V0PT4NjK9WYYKrVCf1bjLlVImNBEcXfvlUTrIYO8y6ptvoUsBQky5pQRvP 99Pn42WfyLy50aII6+vyudD4T0yLjXAz4KteUttxtIte64m/F9/7GEIZAxTUcLyOq/7bP4le h39jBckwc62iYzeK/VkU/bMMh2D68Z3QylMnhhcW27BcgQHPKsHhmFa2SNytYcuQiSdf9+pj 4i32ETz1nJAvYAAqgTF/0PL+8ZNQoEpe/n9woMKrlZrqD4EgFmhQ3bNVhlaXz1nuTZDrwPt1 yMxBuUNbCF4jFnaruwrSiGTRoIfUZQwAjQglahrV4/mcjfnvbNoseHX0PKd9q+wjg7MIjWqr f2CI8Fa6MdanqwYphz43I2yXANKFZuMWsWqyQYlvGuPUlUUcAL3stp24RkzDB1Q+JS0IZJST T2JSu0aTfUdWVNqr2UI19eX+zxbOTckSi3Ng14ezG8ZX194ZH10b8JzntQOwmA20pd5JDhug zQfASER+CZDiPPcQ4mvC4y7rMrfV6XGQbDynC3ekDxo8SC5SvjaczXMwXg6SZ8iFtEWmEwW9 r7zPjjIPDrX8w5LXBgxArM5o/HbERpc2EdAvMh1D7LC0SvmoE7fBKxsicVBe4h6vXjEZ+LLr /wuZiBld9OnxAUIpwptbBspO6WKTQYvgFH2OeDG27hiE5P4Xs4WSp5j9ez8OVB1iZnA2nCQ+ tNTjO8c+C/P92vPLx5+bpGRXTXMNaLh34PS3ZsYoUDkKZNhczRZUWJ7nynSbeeyF+QW7SLwA qY7O7dyk9LFTsfJqRQJ7tWnIAjJPCwmSgQ8Kl0UJ
Message-ID: <5689163e-1113-ff97-b94c-2d8d3550cafb@nwtime.org>
Date: Sun, 14 Jun 2020 13:46:45 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <13D6D5C7-090A-4C68-8F0B-EA6DE18FB1E9@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/zhuBvbiGb93BIejX2cNob44nK2E>
Subject: Re: [secdir] [Ntp] Secdir last call review of draft-ietf-ntp-mode-6-cmds-08
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: Sun, 14 Jun 2020 20:46:52 -0000
On 6/13/2020 9:10 PM, Karen O'Donoghue wrote: > Folks, > > All of this was discussed during the development of this document. There was strong working group consensus to not publish as Standards Track. I recall discussion about this in the WG meetings I attended. Was the "final" decision made at the WG meeting I was unable to attend, the meeting where all of the other proposals I had in various stages of adoption were ... removed from consideration by the WG? > As described, there were concerns about the solution. I don't know what you mean by "the solution" - please clarify? I also don't know what these "concerns" are. Please clarify. > The working group has gone back and forth between historic and informational. It should be Standards track, and optional implementation. H -- > Regards, > Karen > >> On Jun 13, 2020, at 8:27 PM, Harlan Stenn <stenn@nwtime.org> wrote: >> >> On 6/13/2020 11:15 AM, Brian Haberman wrote: >>> Thanks for the review, Daniel. A quick follow-up below for those of you >>> playing along at home... >>> >>>> On 6/13/20 11:18 AM, Daniel Franke via Datatracker wrote: >>>> Reviewer: Daniel Franke >>>> Review result: Ready >>>> >>>> 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 with the intent of improving security requirements and >>>> considerations in IETF drafts. Comments not addressed in last call may be >>>> included in AD reviews during the IESG review. Document editors and WG chairs >>>> should treat these comments just like any other last call comments. >>>> >>>> This document describes a historic protocol whose design falls far short of >>>> modern IETF standards. Its myriad issues are well-described in the Security >>>> Considerations section. >>>> >>>> There has been some debate as to whether the appropriate status for this >>>> document is Historic or Informational. I believe the currently-intended >>>> Historic status is more appropriate. The argument I have heard repeatedly in >>>> favor of Informational status is that it is not appropriate to classify a >>>> protocol as Historic until a better alternative exists with a published >>>> specification. I believe that better alternative exists, which is to have no >>>> standard at all. It's perfectly fine for NTP monitoring and management >>>> protocols to be vendor-specific. In virtually all legitimate uses ("legitimate" >>>> so as to exclude RDoS attacks), both sides of the protocol run on systems >>>> managed by the same organization and the need for vendor-specific tools is not >>>> a practical issue. Lack of standardization is the already the status quo, since >>>> there are many widely-used NTP implementations out there but only the Network >>>> Time Foundation implementation and its derivatives (such as NTPsec) support >>>> this protocol. I know of nobody who has ever been inconvenienced by this; >>>> standardization is a solution in search of a problem. >>>> >>>> >>> >>> Interestingly enough, RFC 1305 actually says this... >>> >>> "Ordinarily, these functions can be implemented using a >>> network-management protocol such as SNMP and suitable extensions to the >>> MIB database. However, in those cases where such facilities are not >>> available, these functions can be implemented using special NTP control >>> messages described herein." >> >> Why is RFC 1305 even being brought up in this situation? >> >> NTPv3 was updated to NTPv4. >> >> During that update, mode 6 and mode 7 were inadvertently not included. >> >> RFC 5905 was developed, as was 5906 and 5907. But mode 6 is still in >> active use and deserves a proper, updated specification. >> >>> SNMP exists and the NTP WG published RFC 5907 to cover the MIB support >>> needed by NTP. I believe that also counts as a better alternative. >> >> Unbelievable. >> >> TTBOMK, the only implementation of 5907 is the one in the reference >> implementation, and in the 12 years it has been out there we have had NO >> reports of it being used. Furthermore, it was implemented USING MODE 6 >> PACKETS! >> >> The only known SNMP interface to ntpd, ntpsnmpd has not seen significant >> updates since 2010. >> >> The mode 6 interface to ntpd, ntpq, remains in continuous development >> and evolution. >> >> Please identify any other implementations of 5907. If you find any, how >> significant are they? Are they proprietary 5907 implementations? What >> implementations to they work on? >> >> Please show how SNMP is a better way to monitor and control NTP than ntpq. >> >> Please show me a working deployment of SNMP controlling NTP, and then >> please compare the number and quality of these deployments with those >> that do the same with ntpq. >> >>> Regards, >>> Brian >>> >>> >>> _______________________________________________ >>> ntp mailing list >>> ntp@ietf.org >>> https://www.ietf.org/mailman/listinfo/ntp >>> >> >> -- >> Harlan Stenn <stenn@nwtime.org> >> http://networktimefoundation.org - be a member! >> >> _______________________________________________ >> ntp mailing list >> ntp@ietf.org >> https://www.ietf.org/mailman/listinfo/ntp > -- Harlan Stenn <stenn@nwtime.org> http://networktimefoundation.org - be a member!
- [secdir] Secdir last call review of draft-ietf-nt… Daniel Franke via Datatracker
- Re: [secdir] Secdir last call review of draft-iet… Brian Haberman
- Re: [secdir] [Ntp] Secdir last call review of dra… Harlan Stenn
- Re: [secdir] [Ntp] Secdir last call review of dra… Karen O'Donoghue
- Re: [secdir] [Ntp] Secdir last call review of dra… Harlan Stenn
- Re: [secdir] [Ntp] Secdir last call review of dra… Brian Haberman
- Re: [secdir] [Ntp] Secdir last call review of dra… Harlan Stenn
- Re: [secdir] [Ntp] Secdir last call review of dra… Brian Haberman
- Re: [secdir] [Ntp] Secdir last call review of dra… Harlan Stenn