Martijn van Duren <openbsd+t...@list.imperialat.at> wrote: > 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.
You have selected defaults that noone will naturally use in their existing *OR NEW* environment, and they could spend a lots of time debugging this. > 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. Yes, probably hmac-md5 hmac-md5 is not insecure. You've been told your premise for changing the hmac is unsound, since you started > 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 cipher is not the hmac. It is illogical to tie the default for one to the other. > > 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. Wrong. Any hmac completely satisfies the requirement -- today and forever. As a rule, a crappy hash inside a hmac construction makes for a good hmac. There are people who want to kill old hashes, which is a good effort. Removing old hashes everywhere is a big effort, and lots of compatibility breaks will be painful. So it is important to change the most unsafe constructions first, and it is OK to delay disruptive change for the safe constructs. Unfortunately those people are a cult who ignore the case that there are safe constructs, and they wants to break everything at once, no matter how inconvenient it is. Did they send you a card to carry? > 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 admin commmunity is well aware of "cipher", and generally know how to debug that. They are less aware there is a secondary "auth", and I suspect being unaware of this layer causes more pain. > 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. For a made-up and incorrect security reason, let's screw all the unfamiliar people trying to get work done quickly with the software, maybe they'll just install the snmp package tools and you won't have to worry about complaints.
