On Wed, Jun 24, 2020 at 9:37 AM Roman Danyliw <[email protected]> wrote: > > 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.
Awesome, thank you. I've just pushed a new version -13 with this (and Ben's comments). Thank you again, W > > [snip] > > Regards, > Roman -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
