Mike Bishop has entered the following ballot position for draft-ietf-bfd-optimizing-authentication-33: Abstain
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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- If there are no implementations and no plans to implement, why are we publishing this? I support Deb's DISCUSS regarding the term "strong authentication" throughout. MD5 and SHA1 are *not* strong. In other contexts, they are the primitives that are used when stronger hash functions are too expensive and the additional security doesn't justify the cost. I also support Gorry's DISCUSS on "optimized". I understand the reasoning, but that term doesn't make it clear what property is being improved without loss of function. In Section 10, it even asserts that this "enhances the ability to authenticate a BFD session" when in fact this explicitly *reduces* the authentication of the session. Perhaps this should be "lower effort" instead? Maybe even "lazy", if that's not seen as too judgmental? The rationale for reducing overhead in sending packets that effectively say "nothing has changed" seems reasonable at first glance. However, it seems to me that an attacker who can drop the "significant change" packets could carry out an attack by fabricating "nothing has changed" messages and preventing detection of a change. "Nothing has changed" is still a message that needs to be protected. The requirement to "periodically test the session using the strong authentication mechanism" attempts to bound this risk. This should be discussed in the Security Considerations, emphasizing that the period used is the amount of time the parties are willing to allow an attacker to conceal a state change they attempted to communicate.
