https://gitlab.com/NTPsec/ntpsec/issues/446
This is likely to involve some discussion so I moved it here where that will be more convenient. We should be supporting longer digests. Wikipedia says: NIST's directive that U.S. government agencies must stop uses of SHA-1 after 2010 was hoped to accelerate migration away from SHA-1. https://en.wikipedia.org/wiki/SHA256 There is no panic on fixing the bug since it won't happen unless you setup your keys file to (try to) use a digest type with a longer hash. I see several options: Reject digest types that don't fit. This is what ntp classic does. It's simple to implement. It fixes the buffer overrun but doesn't support longer digests. Truncate longer digests. This is simple to implement (4 lines of code), but I don't want to think about the security. (or waste the time of any security geek, or give them an opportunity to snicker at us, or ...) Make MAX_MAC_LEN bigger. This seems like a bad idea since the current max size is wired into RFC 7822 (May 2017). But there is an escape: "unless a longer MAC is agreed upon by both client and server". Anybody using a longer digest has obviously agreeded. It's simple to implement. It's very likely to lead to compatibility troubles when we want to use extension fields. Put larger digests into a new type-length extension. This seems like the right approach. We'd have to get a type code from IANA. That could be complicated - politics rather than technical. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel