Adam Roach has entered the following ballot position for draft-ietf-rtgwg-yang-key-chain-20: No Objection
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-rtgwg-yang-key-chain/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - The second paragraph in the Abstract seems very specific for an Abstract. Since this variation is covered in the Introduction, consider removing it from the Abstract. - Since the syntax in section 1.2 is used only in section 3.3 (from which I kept referring back to it), consider moving it down into section 3 somewhere. - Section 2.2 describes a scheme in which the key with the "most recent send lifetime" is used for sending. The data model allows for lifetimes to be indicated with "always." It seems that there should be treatment of the interaction between "most recent" and "always". - The second paragraph of section 3 is a bit non-obvious on first reading -- consider spelling out that one chain has a valid send key but invalid receive key, and vice-versa. - Copyright notice in the YANG file is 2015. Is that intentional? - On page 11, in "grouping lifetime", "case start-end-time", "choice end-time", "case infinite", "description", replace "end-time in infinite" with "end-time is infinite". - On page 14, there's a assertion that hex allows specification of "greater entropy with the same number of octets." It might be worth qualifying this as *stored* octets, since it's demonstrably more octets on the wire. - Section 5 discusses the use of a KEK, distributed out-of-band, to decrypt the keys stored in this format. There appears to be no affordance for indicating the identity of which KEK to use, which would come in handy for the types of key rotation schemes I'm familiar with. Mostly, I'm worried about the "try it and see if it works" approach when you have two valid KEKs (as during a transition), as it's not clear that you will be able to distinguish success from failure in all cases. - Section 5 also suggests keys be encrypted or obfuscated on the device that is to use them, presumably in a way that can be decrypted or unobfuscated using information also on the device. I don't know what the current security area thinking around this is, but given that the information needed to retrieve plaintext keys is necessarily present on the device, this seems like a fig-leaf that provides an illusion of security without providing any real benefit. That mis-impression seems potentially harmful. - The IANA considerations section gives the YANG module prefix as "ietf-key-chain". The YANG module itself defines the prefix as "key-chain". I assume these should match each other? _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
