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

Harlan Stenn <> Wed, 17 February 2021 02:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DDF113A142A; Tue, 16 Feb 2021 18:31:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bhyA0r4wG-Dy; Tue, 16 Feb 2021 18:31:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3AD373A1427; Tue, 16 Feb 2021 18:31:37 -0800 (PST)
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4DgMKf6hnHzMNGB; Wed, 17 Feb 2021 02:31:34 +0000 (UTC)
To: tom petch <>, Benjamin Kaduk <>
Cc: Dhruv Dhody <>, NTP WG <>,,,, Dieter Sibold <>,
References: <> <> <> <> <> <> <> <>
From: Harlan Stenn <>
Autocrypt:; 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: <>
Date: Tue, 16 Feb 2021 18:31:34 -0800
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: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Ntp] [Last-Call] 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: Wed, 17 Feb 2021 02:31:43 -0000

On 2/16/2021 8:52 AM, tom petch wrote:
> On 15/02/2021 23:48, Benjamin Kaduk wrote:
>> On Mon, Feb 15, 2021 at 05:36:46PM +0000, tom petch wrote:
>>> On 15/02/2021 01:11, Benjamin Kaduk wrote:
>>>> Hi Tom,
>>>> On Tue, Feb 09, 2021 at 10:23:57AM +0000, tom petch wrote:
>>>>> On 08/02/2021 17:05, Dhruv Dhody wrote:
>>>>>> Hi Tom,
>>>>>> Thanks for your detailed review. Lets discuss the security first -
>>>>>> On Mon, Feb 8, 2021 at 6:07 PM tom petch <>
>>>>>> wrote:
>>>>>>> This is my second response to this Last Call, about a possible
>>>>>>> security
>>>>>>> issue.
>>>>>>> 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?
>>>>>> Good question. While it is easy to restrict the use of MD5 by
>>>>>> adding a
>>>>>> must statement, I want to check if it is a good idea. The YANG model
>>>>>> is written in such a way that it supports older versions of NTP as
>>>>>> well. Would barring MD5 configuration be an issue if there are older
>>>>>> implementations in the network still? I think perhaps adding a
>>>>>> warning
>>>>>> in the description is a good idea. I did a quick search and dont see
>>>>>> other YANG models doing a check either. Would be good to get some
>>>>>> guidance on this.
>>>>> Dhruv
>>>>> After many years, Security (AD, secdir, advisor) still have the
>>>>> power to
>>>>> surprise me but I would still be surprised if Security were happy with
>>>>> an I-D which places no constraint on MD5 when the IETF has
>>>>> published RFC
>>>>> deprecating its use and NTP has RFC8573 which specifically
>>>>> deprecates it.
>>>>> Yet Security may not realise this from reading this I-D since the
>>>>> unrestricted use of MD5 is not immediately apparent so my post was
>>>>> aimed
>>>>> at bringing this to the attention of Security.  As to whether this
>>>>> needs
>>>>> a note in Security Considerations or enforcing by YANG or both I am
>>>>> less
>>>>> clear on - that is up to Security.  If the YANG is to deprecate it,
>>>>> then
>>>>> the features in ianach make that possible.
>>>>> Whether or not MD5 is widely used in the field is irrelevant.  The
>>>>> IETF
>>>>> consensus it to deprecate its use and I am sure that the IESG will
>>>>> want
>>>>> this I-D to do just that.
>>>> Thanks for flagging the issue; it's good to have many eyes looking
>>>> out for
>>>> these things.
>>>> That said, I think recent practice has been to not take a strict
>>>> hard line
>>>> that MD5 cannot be used ever, and that non-cryptographic uses for
>>>> legacy
>>>> compatibility can be retained, when accompanied by a disclaimer that
>>>> the
>>>> use of MD5 is not for cryptographic purposes and that MD5 is not a
>>>> secure
>>>> cryptographic hash function.
>>>> There is an example of this buried in my remarks at
>>>> that
>>>> resulted in the text now found at
>>>> .
>>> Ben
>>> Thank you for noticing:-)
>>> The -10 that I reviewed had
>>> - MD5 is used to turn an IPv6 address into a 32-bit identifier
>>> - MD5 can be used for authentication without constraint
>>> - AES-CMAC cannot be used for authentication.
>>> I do not have a view on the first but see the second and third as
>>> contradicting RFC8573 and so in need of change.  Allowing AES-CMAC I see
>>> as not controversial but do not have a view as to what to do with MD5
>>> used for authentication e.g.
>>> - allow without constraint
>>> - allow, but deprecated, in the YANG
>>> - allow with a note in Security COnsiderations
>>> - do not allow in the YANG
>>> etc.
>>> I am still sitting on the fence on that issue, lacking the secuirty
>>> insight as to what would be acceptable, to you and the IESG.
>> I would mostly have expected the MD5 authentication option to be split
>> off
>> into a separate YANG module that aguments the base one, or maybe hidden
>> behind a YANG feature, in order to give implementations the ability to
>> "do
>> the right thing" (that is, expose only the modern crypto) while remaining
>> compliant with the primary YANG module.  As far as I know, either of
>> those
>> options would still make it pretty trivial to also expose the MD5
>> functionality for legacy compatibility (which is in some different sense
>> also "the right thing to do", at least for now), but would make it clear
>> that it's not endorsed by the IETF to the same level.
> Ben
> Thank you for the suggestions.  I will pursue it with Dhruv and see what
> he wants to do.  YANG feature would seem the simpler option to me but
> either sound fine.

For whatever it's worth, I'm in favor of simple, clear, honest information.

> Tom Petch
>> -Ben
>> .
> _______________________________________________
> ntp mailing list

Harlan Stenn <> - be a member!