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 <daedulus@xxxxxxxxxxxxx> >>>>>> 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 > ntp@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ntp > -- Harlan Stenn <stenn@xxxxxxxxxx> http://networktimefoundation.org - be a member! -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
