On 2/19/2021 8:34 AM, tom petch wrote:
On 19/02/2021 15:05, Salz, Rich wrote:
I thought a Yang model was supposed to be an on-the-wire
representation of what the server did. Am I wrong? If I'm right, then
the issue around MD5 is with the server, not this doc.
Rich
There are two issues with MD5 and NTP.
One is security, where a crypto-hash is used to authenticate NTPv4
packets, and the hash specified in the NTPv4 base spec was MD5 but
this was updated by RFC8573 so that MD5 is now deprecated. I picked
up on this in my first review, that the YANG model used MD5 and made
no mention of its deprecation. I knew that RFC8573 should be included
but was unclear whether or not it would be acceptable to still include
MD5. Ben, Security AD, said yes, we should, and that is what we now
have (along with a number of other hash). My recent comment was that
the Netconf WG label SHA1 as obsolete so should we include it? and
what about such as SHA3? The more options the greater a risk of
mismatch but that is not an issue I am equipped to resolve, likely one
for the IESG (much as I hate generating work for them).
The other MD5 usage is generating a 32-bit identifier with a good
probability of being unique, for entities with IPv6 address, and that
I see no problem with, as Ben confirmed. That means that the I-D will
reference the MD5 RFC, which is Informational and so potentially a
downref. Again, one for the AD to resolve (which is why I put it
first on my previous post).
There is another problem. Because MD5 is deprecated, some software
development organizations have checks that prevent use of MD5. The test
suites will include such checks, and the software will normally not ship
if the checks detect presence of MD5 in the product. Of course there are
ways around, but they are not quite as simple as replacing MD5 by
SHA256, even for those "non crypto" cases.
-- Christian Huitema
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
