Re: [MIB-DOCTORS] Fix of Security Guidelines for IETF MIB Modules

[Warren Kumari <[e-mail]>]

On Tue, Oct 9, 2018 at 6:55 AM Glenn Mansfield Keeni <[e-mail]>
wrote:

> Hi,
>
>  > This seemed like a better fix than just changing the i.e to an
>  > e.g, and so I went ahead and made that change.
> Thanks. That is one nit less!
>
> The discussion on further fixes will continue..
>
>
Awesome, thank you!
W



> Glenn
>
> On 2018/10/09 9:11, Warren Kumari wrote:
> > On Sun, Sep 30, 2018 at 10:16 PM Glenn Mansfield Keeni <[e-mail]
> >
> > wrote:
> >
> >> Hi,
> >>   > disclosure.  For example, consider a hostname.  Are we willing to
> >>   > do major surgery on this paragraph, probably splitting it into two,
> >>   > and thus affecting the structure of these security considerations?
> >> I would suggest that we take this in 2 steps.
> >> First, fix the (now) obvious nit.
> >> +--------------------------------------------------------------------+
> >> OLD:  Some of the readable objects in this MIB module (i.e., objects
> >>          with a MAX-ACCESS other than not-accessible) may be considered
> >>          sensitive or vulnerable in some network environments.
> >>
> >> NEW:  Some of the objects in this MIB module may be considered sensitive
> >>          or vulnerable in some network environments.  This includes
> INDEX
> >>          objects with a MAX-ACCESS of not-accessible, and any indices
> from
> >>          other modules exposed via AUGMENTS.
> >> +---------------------------------------------------------------------+
> >>
> >
> > This seemed like a better fix than just changing the i.e to an e.g, and
> so
> > I went ahead and made that change.
> > Please, if anyone objects, let me know and I'll change it back (it isn't
> > really my text, but I figured it was clearly enough broken that I'm
> > qualified to have an opinion).
> >
> >
> >
> >> Next, discuss and arrive at the decision (and maybe text too) on whether
> >> we are willing to do major surgery etc. I agree that in the current form
> >> (even with the nit-fix) the security considerations remain incomplete.
> >>
> >
> > This discussion should still continue...
> >
> > W
> >
> >
> >
> >>
> >> Glenn
> >>
> >> On 2018/10/01 0:40, Randy Presuhn wrote:
> >>> Hi -
> >>>
> >>>
> >>> On 9/30/2018 5:59 AM, Glenn Mansfield Keeni wrote:
> >>>>
> >>>> Hi,
> >>>>   >         What
> >>>>   >         is the point of limiting read access and then sending the
> >>>>   >         information in the clear?
> >>>> Total agreement. Sending info in the clear is by default NG and must
> >>>> be strongly discouraged.
> >>>> It will help to have some proposed replacement text for
> >>>>   > OLD:  It is thus important to control even GET and/or NOTIFY
> access
> >> to
> >>>>   >        these objects and possibly to even encrypt the values of
> these
> >>>>   >        objects when sending them over the network via SNMP.
> >>> ...
> >>>
> >>> As I wrote previously, this would be editorially tricky since the
> >>> paragraph currently conflates "sensitive" (which I take to mean
> >>> "that which should be protected from disclosure") with "vulnerable"
> >>> (which I take to mean "that which should be protected from
> >>> modification").  It *is* possible to have something which one wants
> >>> to protect from modification, but there's no need to protect it from
> >>> disclosure.  For example, consider a hostname.  Are we willing to
> >>> do major surgery on this paragraph, probably splitting it into two,
> >>> and thus affecting the structure of these security considerations?
> >>>
> >>> Randy
> >>
> >>
> >
>
>

-- 
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