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