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

Warren Kumari <warren@kumari.net> Tue, 09 October 2018 11:56 UTC

Return-Path: <warren@kumari.net>
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114261312EE for <mib-doctors@ietfa.amsl.com>; Tue, 9 Oct 2018 04:56:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwRfEkweLZbX for <mib-doctors@ietfa.amsl.com>; Tue, 9 Oct 2018 04:56:30 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10CF1312E4 for <mib-doctors@ietf.org>; Tue, 9 Oct 2018 04:56:29 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id x12-v6so1491382wru.8 for <mib-doctors@ietf.org>; Tue, 09 Oct 2018 04:56:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2x0vI+VSuS4ur4eY/GBNt6ak7uk8Odn7cLNvZ/X1WRQ=; b=Izheufq//9hIrhq6+AIr9ZbiD+e/v6qAad/67u+WKflDemfzX9RM4733v4zF+g+67b 8SewkEzJV2X1uY/OrKlVE4yuGGspZAAzQ+gzvIeKqT3jLRQO8Qrqi38bRXohQnG5U7cM azkdbrRO+PjDUEo2S+CHinMZ/GxNQ7X8ePIjpaQ/6BRCvm4qTsDnxfszLD/IBC50xS8i 1tY+NqHmBC2yX7Flj66nnOUw5BVXhIU+CkiUYrOeN98eNHDOuC7FD7d60QBqFmsiv54V Lp9QEu4zMF0EYX53yb8EBZgj3DsFDEl2TfPv/YEhBDfh8N50RlOqy+4XuA898nnYH42u R5fQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2x0vI+VSuS4ur4eY/GBNt6ak7uk8Odn7cLNvZ/X1WRQ=; b=et+QIZFF1p4zeL4FPFpX0EW8nuNHZlEkVcbo0oZVqUT7E73hhWvp/o7AkDCaDdSIxR jlxI+GyzGkWzRNZuV1+JOVT9p/fxwthy9l2eWsLPYiKUxZr3BO/TH+2gH9e+giqxK8EM mdbcQoHsDMMhMzyQ1yQIlkjIHnKHytbKCffPCq5v+W3J8YLykmhjZM4zKwFKjZTivJis SMWEXus66sqiP25yloMObwbZh56Q8MsOVne4pHr6KZHukdoySk7YbhmNRXKS8lC3xC+o U6dmXNm7aAk6NHQGd8xdkkKQqWmiKcfGsEE426hk6iXT9af8eBczRiJIxcAJ02dR2MWb QHOw==
X-Gm-Message-State: ABuFfojUL9v587Omn1R0RAR7Ys+xb0Ga8cm2nDNnOxlPJNZWC5Pxi2oY vricUyBoor7zwI8n3nXK6faMCvXnIv14t53+soa1HA==
X-Google-Smtp-Source: ACcGV607+XnMTKzvIteGjmB3SWDt3YG86x1nDqSdwjXCE+oBg+375SHMGXlLlyc2vST0qG5UoEU9IKPzPjSLcANs3qI=
X-Received: by 2002:adf:e752:: with SMTP id c18-v6mr21387731wrn.143.1539086187716; Tue, 09 Oct 2018 04:56:27 -0700 (PDT)
MIME-Version: 1.0
References: <7f59ba0b-1358-1015-cd85-4c470ad73d9a@cysols.com> <f8bce0d0-cd96-7bd1-c785-e459860d863d@alumni.stanford.edu> <d54348ed-87da-8120-0b37-82143cdad3d3@cysols.com> <68a4912f-f0b4-1ecd-5341-3ee3e9adc8ce@alumni.stanford.edu> <a9615a5c-9a83-ac3c-cb68-c7ca4a5379a9@cysols.com> <CAHw9_iKWZJvCbF=tsE06mLoVVEWmsVg440dawodkUnBTFjfBNQ@mail.gmail.com> <ab22ea96-61ee-0d80-465d-90cbebbb44c3@cysols.com>
In-Reply-To: <ab22ea96-61ee-0d80-465d-90cbebbb44c3@cysols.com>
From: Warren Kumari <warren@kumari.net>
Date: Tue, 9 Oct 2018 07:55:50 -0400
Message-ID: <CAHw9_iJbPrbo8dFTr3AG8YzC0cSS2p7bsp1iAEYPeOY2gGANrQ@mail.gmail.com>
To: glenn@cysols.com
Cc: randy_presuhn@alumni.stanford.edu, mib-doctors@ietf.org, Ignas Bagdonas <ibagdona@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000007f76530577ca6d5e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mib-doctors/1p5si6GNahDJuS-Zks4A_UpsTWQ>
Subject: Re: [MIB-DOCTORS] Fix of Security Guidelines for IETF MIB Modules
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: MIB Doctors list <mib-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mib-doctors/>
List-Post: <mailto:mib-doctors@ietf.org>
List-Help: <mailto:mib-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Oct 2018 11:56:33 -0000

On Tue, Oct 9, 2018 at 6:55 AM Glenn Mansfield Keeni <glenn@cysols.com>;
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 <glenn@cysols.com
> >
> > 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