Let me give one final pushback, if this doesn't convince you then feel free to commit sthen's diff without my OK, but make sure it stays in sync with snmp(1).
First let me sum up what defaults have changed since 6.9: - community authentication disabled (snmpv1/snmpv2c) - no default community name set set - seclevel moved from none to enc - enc moved from des to aes - auth moved from hmac-sha1 to hmac-sha256 So we're already being quite disruptive with our defaults this release cycle. Chances are that if anyone relies on defaults they're already getting burned, even if we revert the auth one. On Fri, 2021-08-06 at 08:22 -0600, Theo de Raadt wrote: > > That is pretty ridiculous. > > Shall we force users to select their ssh hmacs? Or, maybe you don't > mean users, shall we force admins to select their sshd hmacs before > sshd will startup? But USM does force admins to choose the hmac for each user, that we supply them with a default just means that if the admin chooses to explicitly use the defaults (as in choosing to not explicitly copy our defaults to their snmpd.conf) brings them at risk of things breaking on them the day the defaults are changed. It's become clear to me that defaults for non-negotiable parameters at the protocol level are a bad idea. > > Defaults exist so that systems are easy to use. This discussion has made > it clear that there is no security justification, it is simply a case > of murdering older hash algorithms EVEN IF THEY ARE SAFELY EMBEDDED INSIDE > A HMAC. Maybe, but it also made it clear that relying on the defaults for a protocol (USM) that doesn't allow to be negotiated will make users cry. Also note that the USM keys (both auth and enc) are derived from a password by the hashing algorithm chosen for auth. This means they're susceptible to dictionary attacks with the way most people handle their passwords and having a slower hashing function also helps in that regard as well. > > There are circumstances where the sha256 cult are wrong, and this is one > of them. Maybe, but for how long still? We're already being increadibly disruptive this cycle. If there's ever a time to bite the bullet it's now. On Fri, 2021-08-06 at 08:19 -0600, Theo de Raadt wrote: > Theo Buehler <t...@theobuehler.org> wrote: > > > > hmac-md5 might not be vulnerable, but snmp doesn't use pure hmac-*; in > > > the case of md5 and sha1 it strips the result back to 12 bytes (for > > > sha256 it's 24 bytes). I'm not saying that is insecure because of it; I > > > haven't seen any research on the truncation of HMAC, but when combined > > > with known problematic hashing algorithms it doesn't increase my > > > confidence level. > > > > The hash used in an HMAC construction needs much weaker properties than > > a cryptographic hash (in particular no collision resistance). Basically, > > that's because there's still a private key involved that isn't known to > > the attacker. The brokenness of md5 and sha1 isn't strong enough yet to > > compromise hmac-md5 and hmac-sha1. > > > > The rule of thumb is that you need to keep at least half the size of the > > hash in a truncated HMAC.Since SHA-1 has 160 bits and MD5 128 bits, > > keeping 12 bytes is fine. This corresponds to "96 bits of security". > > This isn't all that great by today's standards, but far from completely > > bonkers. > > to conclude, snmpd configuration should be defaulting to the *industry > standard* hmac that has highest interopability, because there is no > cause for being the first snmp stack to become non-interoperable. So you mean we should default to hmac-md5? Because p5-Net-SNMP and netSNMP default to hmac-md5 and I've seen some machines (HP printers) that only support hmac-md5, but not hmac-sha1. Shall we also revert back the DES? AES for USM is part of RFC3826, which is also not standard. It's also not the default in many implementations (both p5-Net-SNMP and netSNMP default to DES) and the same HP printers mentioned above only support DES. > > The older hmac continues to satisfy the security requirement. I wouldn't equal "This isn't all that great by today's standards, but far from completely bonkers." to "continues to satisfy". But sure. > > The newer mac is causing users problems, because no other systems are > configured thus, so you are simply adding an irrational hurdle to snmpd > use. But the change to AES also causes the same breakage for users who choose to go with the default (which was DES) and DES is still the default for most USM implementations out there. > > The addition of these advanced mac's to the spec is really just > ASPIRATIONAL -- they are added for future community use, and possible > mainstream adoption in the next decade. There is nothing insecure to fix > here. There is no mandate to push people towards maximally non-interoperable > defaults. When stated this way, I hope you see it the same way. > > I recommend changing it back to the industry standard. > I see where you're coming from, but I still disagree. But let me summarize: - We're being increadibly disruptive on the defaults this cycle. - We're not taking away anyones ability to interoperate: they just need to add 4 little words per user. - Defaults for USM are a bad idea, because there's no negotiation between agents. - sha256 is slower then md5/sha1 which should help with slowing down brute force attacks against the hmac key if they're password derived. - From the implementations I've seen in the wild hmac-md5 is the default for most, not hmac-sha1 - Similar DES is still the default for most implementations, not AES - snmp(1) should be kept in sync with snmpd(8) Given all this I'm inclined to remove the defaults all together and let people get errors on startup, so that they know that they need to be explicit; as per sthen@'s previous suggestion. This will also solve any des-incompatibility issues that might arrise from the default change. But if that's not desired, as stated: Go ahead with sthen's diff without my OK and make sure that snmp(1) is brought along. martijn@
