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