Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-sdi-10: (with DISCUSS and COMMENT)

[Roman Danyliw <[e-mail]>]

Hi Warren!

> -----Original Message-----
> From: Warren Kumari <[e-mail]>
> Sent: Tuesday, June 23, 2020 4:21 PM
> To: Roman Danyliw <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; OpsAWG-Chairs
> <[e-mail]>; opsawg <[e-mail]>; Michael Richardson
> <[e-mail]>
> 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 <[e-mail]> wrote:
> >
> > Hi Warren!
> >
> > Thanks for the response and -11.  More inline ...
> >
> > > -----Original Message-----
> > > From: Warren Kumari <[e-mail]>
> > > Sent: Tuesday, May 19, 2020 2:35 PM
> > > To: Roman Danyliw <[e-mail]>
> > > Cc: The IESG <[e-mail]>; [e-mail];
> > > OpsAWG-Chairs <[e-mail]>; opsawg <[e-mail]>;
> > > Michael Richardson <[e-mail]>
> > > 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
> > > <[e-mail]> 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