Deb Cooley has entered the following ballot position for draft-ietf-ace-key-groupcomm-oscore-19: 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/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-ace-key-groupcomm-oscore/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm discussing two general ideas from the draft that I believe might lead to security vulnerabilities. Some of the specific comments in the comment section also help raise those concerns: Monitors: How does the Group Manager know that the monitor is legitimately in the group? What proof does a monitor have to provide? And what access does a monitor have to the group? Can they request authentication credentials of other members? There needs to be a section in Security Considerations that discusses the access a monitor has to the group and how that affects the security of the group. Dedicated nonces: The term 'dedicated nonce' is an oxymoron. The classic definition of a cryptographic nonce is: an arbitrary number that can be used just once in a cryptographic communication. Any value that is 'dedicated' or used more than once is not a 'nonce', perhaps 'id' is a better term. - Section 16: The profile relies heavily on the clients and group managers ability to not leak these nonces. Yet, this is not mentioned in Section 16. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Yoav Nir for their secdir review. General: As I have stated before (on other drafts for this protocol), this protocol presents a complex and complicated set of requirements. This is no different, and it is coupled with at least 8 RFC/drafts that have to be understood to use it. Classically, complex protocols lead to developments that contain flaws due to misunderstanding the requirements to implement. Time will tell for this protocol, maybe only the designers of the protocol will be able to implement correctly. Section 4, para 3: Does the Group Manager supply a member of the group who has not provided authentication credentials themselves (as a monitor is described in para 5) other group members' authentication credentials? Section 5.3: The organization of this section is confusing. The top level section outlines requirements of the form: if X appears, then Y requirements apply, with little explanation as to why one might require or exclude X. Section 5.3.1 and 5.3.2 provide explanatory text for two of the 5 or 6 value/requirements. This whole section would be clearer if the explanatory text was first (in 5.3) and the specific requirements are in subsections after. Section 6.2: When a MAC is used as PoP, is it a keyed MAC? If not, then what exactly is being proven? Is it possession of the static 'dedicated nonce'? Then one has to explain the risks (in Section 16) of leakage of this static value. Section 7.1: This is complicated. Why not merely state that 'stale' OSCORE Sender IDs need to be maintained as unusable until after the group is rekeyed? Why is it appropriate to delete older stale IDs (if this is appropriate for whatever reason, please add a warning in Section 16)? Section 16.1 states that rekeys are done when one or more members leave the group, if that is done, how does the stale list gets to be too large. Section 16.2: So possession of a value (called a nonce in this draft) can be used as a PoP? Seems odd. _______________________________________________ Ace mailing list -- [email protected] To unsubscribe send an email to [email protected]
