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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
