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 <[e-mail]>]

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 <[e-mail]>
>>>>>> 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
>>>> https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ballot/
>>>> that
>>>> resulted in the text now found at
>>>> https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-29#section-11.6
>>>> .
>>>
>>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp
> 

-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!