Sent from my iPhone
> On May 14, 2015, at 9:47 AM, "Stephen Farrell" <[email protected]> > wrote: > > Stephen Farrell has entered the following ballot position for > draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > I'm a yes on this, but am still holding my nose:-) > > The yes is because it's a fine thing to make sure that up-to-date > options for securing protocols are available. > > The nose-holding is because defining multiple options that > aren't significantly different in strength (if one assumes that > key management is the likely weakest link) is a bad plan. > > In case it helps, my main logic for not wanting all these > options is that it is overwhelmingly more likely that the > code to switch between them or react to which you've received > or to configure things will (due to bugs etc.) weaken > security much much much more than the existence of more > than one of these options could ever strengthen security. > (Put another way the probability of a security bug due > to adding N things here is far far higher than the > probability that having N things saves the day when N-1 > of them are no longer considered good crypto at some > point.) > > So by defining more of these you are doing worse than > if you only defined one of these. (The fact that all sha2 > digests have the same internal structure is part of but > not all of this argument.) > > On truncation, I'd argue that if that was a significant > benefit then it'd be used everywhere and it is not. In > fact I don't believe truncation is used anywhere else > when there's no protocol (e.g. PDU/fragmentation) issue > that causes us to want shorter MACs. > > I also believe that even those who for truncation would > agree that the benefit of reasonable-length truncation is > definitely an insignificant benefit, if any, and would > also agree that that's a matter of taste when it comes > to sha2 variants of hmac (assuming the protocol can live > with full length, as in this case). > > Bottom line: Discuss is cleared and I'm out of the way, but > with a heartfelt plea that you ditch all of these but one. And > then ditch truncation too. And so end up with just adding > hmac-sha2 as many other protocols have done. > I agree with Stephen. My yes was because more secure options are defined, but less would be good. Thanks, Kathleen > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
