Roman Danyliw has entered the following ballot position for draft-ietf-opsawg-sdi-10: 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-sdi/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ** Section 3.2. If keying material is being distributed as a certificate, do the expected behaviors of certificate process apply? For example, how is expiration handled? -- If a customer downloads a certificate from the publication server and it is expired, what should be done? -- If a certificate is loaded in the TPM of the device, should the client stop accepting configurations if it expires? ** Section 4.3. “After retrieving the config file, the device needs to determine if it is encrypted or not. If it is not encrypted, the existing behavior is used.” What downgrade protection is assumed or recommended here. A rogue data center employee could re-target a DHCP response to a server of choice which provides only unencrypted, tainted configuration. It would seem that a device expecting an encrypted configuration should not accepted unencrypted ones (or at least this should be a policy consideration). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** I struggled a bit to understand where this solution was applicable. For example: Abstract: “This document extends existing auto-install / Zero-Touch Provisioning mechanisms to make the process more secure.” Section 1: “this document layers security onto existing auto-install solutions to provide a secure method to initially configure new devices”. -- Which “auto-install” and “zero touch provision mechanisms” is this updating? -- What exact preconditions are necessary to make this “solution” (reference architecture?) applicable? Would this still be useful if the “auto-install” mechanism was encrypted? What non-DHCP configurations should be considered? Does the way the device identifier bind to the configuration matter? Because there is little specificity, it is difficult to review the security properties. ** Per the Security Considerations, what new security services does this overlay provide? ** Section 2. Per “This document extends this (vendor specific) …”, what is “vendor specific” about this approach? ** Section 4.2. Per “The operator will then encrypt the initial configuration (for example, using SMIME [RFC5751]) using the key in the certificate, and place it on their TFTP server”, is this always a TFTP server, or is this only an example – I think this is an example? ** Section 4.3. Per “Give up, go home” in the figure, is there a retry procedure? The text above states that “If it cannot decrypt the file, or if parsing the configurations fails, the device will either abort the auto-install process, or will repeat this process until it succeeds.” ** Section 7. Per “An attacker (e.g., a malicious datacenter employee)”, also a malicious shipping agent. ** Editorial -- Abstract. Editorial. I would recommend generalized wording to replace the phrase ‘smart-hands’-type support. -- Section 1. Editorial. “asking the smart-hands to …”, Recommend generalizing this reference. -- Section 1. Editorial. “not intended to be an ‘all singing, all dancing’ fully featured system”, Recommend removing this colloquialism. -- Section 3.1. Typo. s/Each devices requires/Each device requires/ -- Section 3.1. Typo. s/cryptograthic/cryptographic/ -- Section 4.3. Typo. s/dependant/dependent/ -- Section 4.3. s/retrys/retries/ _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
