Hi Warren! > -----Original Message----- > From: Warren Kumari <[email protected]> > Sent: Tuesday, June 23, 2020 4:21 PM > To: Roman Danyliw <[email protected]> > Cc: The IESG <[email protected]>; [email protected]; OpsAWG-Chairs > <[email protected]>; opsawg <[email protected]>; Michael Richardson > <[email protected]> > Subject: Re: Roman Danyliw's Discuss on draft-ietf-opsawg-sdi-10: (with > DISCUSS and COMMENT) > > On Thu, May 21, 2020 at 10:09 AM Roman Danyliw <[email protected]> wrote: > > > > Hi Warren! > > > > Thanks for the response and -11. More inline ... > > > > > -----Original Message----- > > > From: Warren Kumari <[email protected]> > > > Sent: Tuesday, May 19, 2020 2:35 PM > > > To: Roman Danyliw <[email protected]> > > > Cc: The IESG <[email protected]>; [email protected]; > > > OpsAWG-Chairs <[email protected]>; opsawg <[email protected]>; > > > Michael Richardson <[email protected]> > > > Subject: Re: Roman Danyliw's Discuss on draft-ietf-opsawg-sdi-10: > > > (with DISCUSS and COMMENT) > > > > > > On Mon, May 18, 2020 at 6:20 PM Roman Danyliw via Datatracker > > > <[email protected]> wrote: > > > > > > > > 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? > > > > The text in -11 works for me. If you think there are alternatives to using > X.509 in this reference architecture it might be worth mentioning. > > > > > > ** 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). > > > > > > > > > > Thank you very much for your review. > > > > > > I have addressed these (and below) in > > > https://github.com/wkumari/draft-wkumari-opsawg- > > > sdi/commit/22d2ad52983e03309796867db22b88a5960bf039 > > > (and will be posting a new version of the draft soon, once I address > > > other comments as well). > > > For those following along at home, Roman kindly provided me some > > > text to clarify the above. > > > > For the downgrade issue noted above. I think we need a little more text. > > My > concern is around the following text: > > > > Section 4.3: > > After retrieving the configuration file, the device needs to determine > > if it is encrypted or not. If it is not encrypted, the existing > > behavior is used. > > > > If a new device supports this architecture and the deployment environment > supports it too (which should be known), but the device still gets an > unencrypted config, that should be a sign of something suspicious. I would > envision language here that says that devices should abort. > > Added: "If the device has been configured to only support encrypted > configuration > and determines that the configuration file is not encrypted, it should > abort."
The above text would address my concern. Thanks. [snip] Regards, Roman _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
