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

Warren Kumari <warren@kumari.net> Tue, 09 October 2018 00:12 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 BCF58130FA2 for <mib-doctors@ietfa.amsl.com>; Mon, 8 Oct 2018 17:12:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 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] 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 x4a8RJVFzIJk for <mib-doctors@ietfa.amsl.com>; Mon, 8 Oct 2018 17:12:03 -0700 (PDT)
Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 5907B130E94 for <mib-doctors@ietf.org>; Mon, 8 Oct 2018 17:12:03 -0700 (PDT)
Received: by mail-wr1-x442.google.com with SMTP id g15-v6so19952919wru.9 for <mib-doctors@ietf.org>; Mon, 08 Oct 2018 17:12:03 -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=a9fkbKdvqwrvMhAjGiQ4yKpDI8k5wXOnxFBoI9DAbuI=; b=cs3yx/eMr4qGZfNukwKoygyUxtHa21z1l3QARbjtsOHt+1k3VehClgNOi59PJ2O3RO gByohWEOfBryN59YXljyLR7WLSbxMaKPfxbxuGj0FkH7k33s4sWzBeFbSJh2YkyhrRJF FezjK1/zOvw6q9XSinRO1/5uQw/WeOHn31wZYqTbBnf6e93VVQXtr/IFbNyVZm/2Qji6 w/atEH5e+9Hym0j1wOzXZFOxzzlFk+KnJQ7HJ2JJAj1hkZX2Gq1URCtREQxQcyC3OK4h NvMJii+QsMIkEC1na7gGvXkPymbGisHzFPXZnvpb+e1/PH2eV3yVyEd8eHQuTxd1aYYE ipog==
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=a9fkbKdvqwrvMhAjGiQ4yKpDI8k5wXOnxFBoI9DAbuI=; b=AUeD/aEva3QSCgxaR6hGlECdLyvszOwdWm4GpNl4HvUvj/BzUraKzEvDWpY0f049Lf 2AbHRUEpiEuLVi0ZoXEyc5/1jOjn1j6P/II9nQTsZ591FGWp4BKaIsuaEZnKmi8l5N6I PAl92v6Aj4z0McO+P1nbXxLw6E0+7WiKRysr2/AQ7H/9SwflzUMjcxLSLz9kghD5S+lq 2//iSDtknntS90CMWIG9ZK8H3gQn3jQrS1SncKRbEhRZUmfyzcV7hOebJiPl0ECxfnLJ eVi5X860lpZi4A4Z/RXQ6cx/Zwyh1KsyP8hZPxB3ED8PLcvbp4U5OcSi2C+6+WyAHsZ3 8s/w==
X-Gm-Message-State: ABuFfoiTRURI4km7cyn9U5UAO9EPM8hi01v6rOaap3pY/0JdamhQrECe jRL3wZ8sa8VfzJiS6UfbVkvC0hd6K2vvgWbVmKMeEDqE
X-Google-Smtp-Source: ACcGV60v7AQz0fpC6dyR6rl1943KqeUSEdnX+SjoGnle3g6XRm9Y0h95Nb2q6t5pIkrovMXmC7E0Ej+42zDNUVJEAkk=
X-Received: by 2002:adf:e752:: with SMTP id c18-v6mr19608833wrn.143.1539043921523; Mon, 08 Oct 2018 17:12:01 -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>
In-Reply-To: <a9615a5c-9a83-ac3c-cb68-c7ca4a5379a9@cysols.com>
From: Warren Kumari <warren@kumari.net>
Date: Mon, 8 Oct 2018 20:11:25 -0400
Message-ID: <CAHw9_iKWZJvCbF=tsE06mLoVVEWmsVg440dawodkUnBTFjfBNQ@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="0000000000003c89a20577c09631"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mib-doctors/19WI6CwK_rqQ-SwNJ8kVOyPcypg>
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 00:12:06 -0000

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