daedulus@xxxxxxxxxxxxx said:
> 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?
"Allowed" is the key word. Just because somebody published an RFC doesn't
mean that all the gear out in the field will get updated. As Harlan pointed
out, there is a very very long tail on NTP deployments.
I think it makes sense for iana-crypt-hash to include slots for historic
items. If nothing else, it is a good place to say "historic" or "deprecated"
and give references to the details.
If you think a Yang model should discourage using MD5, then I suggest adding
words to say that. Better would be to phrase things so that it also includes
other algorithms that get kicked out of the club after the RFC is published.
I don't know of any place that publishes an up-to-date list of crypto-hashing
algorithms and their status.
----------
I'm looking at iana-crypt-hash@xxxxxxxxxxxxxxx
It says:
id | hash function | feature
---+---------------+-------------------
1 | MD5 | crypt-hash-md5
5 | SHA-256 | crypt-hash-sha-256
6 | SHA-512 | crypt-hash-sha-512
If NTP is the only use, then I'd suggest adding a deprecated note. But I
assume that is used by other than NTP so that may not be appropriate. But
maybe if MD5 is deprecated for NTP it should be deprecated for other uses too.
???
What happened to slots 2, 3, and 4?
Existing NTP code also supports SHA-1
RFC 8573 that deprecated using MD5 with NTP suggests using AES-CMAC. Note
that is CMAC rather than HMAC and that NTP uses it's own scheme rather than
HMAC as described in RFC 6151.
The NTPsec code supports any hash (or CMAC) algorithm that the underlying
library from OpenSSL supports.
--
These are my opinions. I hate spam.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
