On 15/02/2021 03:23, Hal Murray wrote:
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.
I'm missing the big picture. What is Yang supposed to do?
I'd expect it would be describing existing practices. I don't expect it to be
trying to add MUSTs to other RFCs.
I'd be happy with notes that a use case has been deprecated, especially if
there is an RFC to point to.
But unless I'm missing something, Yang is not the place to be trying to
enforce good crypto practices. Most people working on NTP won't pay any
attention to Yang if they even know it exists.
NTP uses MD5 in two places. One is hashing IPv6 addresses to make something
that fits into a slot that only has room for IPv4 addresses. I don't think
there are any crypto/security considerations.
The other is for authenticating packets. RFC 8573 deprecates that usage. A
note in a Yang document saying "using MD5 for authenticating NTP has been
deprecated by RFC 8573" seems like a good idea. I think anything stronger
will be inappropriate. But maybe I don't understand what Yang is all about.
Hal
YANG provides configuration and management for IETF (and other
protocols). I am not sure which MUST you have in mind but RFC5905 is
updated by RFC8573 and I see nothing in this I-D as it stands that goes
beyond those RFC.
It is not the job of YANG to enforce good practice but it is the job of
an author to produce something that gets through the IESG and, in some
areas, the IESG is ahead of common practice, the use of IPv6 and
Security being two where I regularly see the IESG wanting more than I
see in the world at large. (Thus the IETF has just produced an I-D
updating 100 or so RFC to deprecate the use of older versions of TLS;
this does not surprise me but I do not seeing increasing the security of
the Internet, perhaps the opposite, but then this is security!)
So MD5 may be in widespread use for security in lots of protocols but
that does not mean that an I-D (implicitly) recommending its use will
pass the IESG! I do not know the answer to that which is why I posted a
separate e-mail on the topic intending to catch the eye of a Security
I-D:-). The I-D has passed a secdir review but that may not have
realised the implication buried in the YANG. Perhaps a note in the
Security Considerations deprecating MD5 is enough but that is not my call.
Tom Petch
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
