Stephen Farrell has entered the following ballot position for draft-ietf-opsawg-hmac-sha-2-usm-snmp-06: Discuss
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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for defining these. I do have a thing do briefly discuss before balloting yes. I'll be getting out of your way very shortly, but I want to check first to see if you agree with me that this could be simpler and more useful. I note the following: - You're defining a bunch of HMAC options. - Additional options for fun isn't a good idea with crypto. - There may be platforms that do not have good APIs for SHA224 or SHA384. - HMAC-SHA256 without any truncation is considered perfectly fine for this purpose and is widely used elsewhere. - You don't need truncation for protocol reasons. To me, that implies that this would be better if it *only* defined a non-truncated HMAC-SHA256 option and if all of the rest were removed. Do you agree that doing so would achieve just as much of a security improvement, but with less complexity for implementation, test and interop? If so, should we just do that? _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
