Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities

Benjamin Kaduk <kaduk@mit.edu> Wed, 28 October 2020 18:57 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECA03A0B73 for <ietf@ietfa.amsl.com>; Wed, 28 Oct 2020 11:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 SZPg4a6Sxxa5 for <ietf@ietfa.amsl.com>; Wed, 28 Oct 2020 11:57:57 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ECA43A0B6F for <ietf@ietf.org>; Wed, 28 Oct 2020 11:57:56 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09SIvouR003942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Oct 2020 14:57:54 -0400
Date: Wed, 28 Oct 2020 11:57:50 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Michael Thomas <mike@mtcc.com>, The IETF List <ietf@ietf.org>
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Message-ID: <20201028185750.GI39170@kduck.mit.edu>
References: <09B0A1A1-6534-4A44-A162-9962FFF8D8B8@cisco.com> <362d68dd6117452f925322f8180de423@cert.org> <B864FFAE-3E3E-4CEF-B832-4552C8BAE70B@cisco.com> <61d17bb9-9056-ecbd-e7f8-e7bd5bd27d97@mtcc.com> <01RRASWVT8OO005PTU@mauve.mrochek.com> <3552cbcd-2d6e-da06-5d66-d0218f6c57ac@mtcc.com> <F8E98E25-CAEE-43CF-B65C-3186844F4A29@cisco.com> <5d4bc8a9-4955-dde3-6022-7bdb2f5dc7ae@mtcc.com> <20201028184208.GF39170@kduck.mit.edu> <f7e0ec4a-4d61-076c-4638-5e9683f7b505@joelhalpern.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <f7e0ec4a-4d61-076c-4638-5e9683f7b505@joelhalpern.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/vGX_KAqOaAovGhW7jpTh3hDib1w>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2020 18:57:59 -0000

On Wed, Oct 28, 2020 at 02:53:56PM -0400, Joel M. Halpern wrote:
> I hope I am missing something.
> I have trouble thinking of a case where a security vulnerability in our 
> work could be reasoanbly captured in an erratta that is anything other 
> than "held for future update".

Yes, I was assuming these errata would end up in HFDU.

-Ben

> The errata system is not an issue tracker for RFCs.  Accepted errata are 
> not supposed to be changes to the WG agreement, even if the WG got it 
> wrong.  They are supposed to be cases where the words on the page do not 
> say what the WG meant.  this can be a missing (or added "not", or 
> verbiage so opaque that anyone not in the room can't figure out what it 
> means (although most of the time the RPC catches those before RFC 
> publication.)
> 
> it is not for the cases where the WG agreed on a protocol that has a 
> security hole, bug, or potential misbehavior.
> 
> Heck, in the case of 8200 I have to agree with the AD that an errata was 
> not the way to fix ambiguous wording that the WG agreed on, even when 
> folks later came up with an interpretation that had not been considered 
> by the WG.  Errata simply are not for things that change existing WG 
> agreements.
> 
> Yours,
> Joel
> 
> On 10/28/2020 2:42 PM, Benjamin Kaduk wrote:
> > On Tue, Oct 27, 2020 at 11:27:13AM -0700, Michael Thomas wrote:
> >>
> >> On 10/27/20 11:00 AM, Eliot Lear wrote:
> >>> I think what you are pointing out is that maybe it would help if these
> >>> things were properly tracked against anything that would update or
> >>> obsolete existing work.  We might even be able to automate the
> >>> response along the lines of:
> >>>
> >>>    * A working group is currently working on an update.  Please feel
> >>>      free to join in the fun at...
> >>>    * A working group is currently working on a replacement (e.g.,
> >>>      obsolete). Please feel free to join in the fun at ...
> >>>    * No current update is in progress.  In addition to filing an
> >>>      erratum, we invite you to provide an update through our errata
> >>>      process, and perhaps through our standards process.  You can
> >>>      contact <insert AD here> for more information.
> >>>
> >>>
> >> My impression is that errata has a pretty high barrier to entry if it's
> >> potentially controversial. There doesn't seem to be any easy mechanism
> >> to do a one off update that requires wg buy in to get enough eyeballs on
> >> the problem to make certain that the fix is correct. it's like you need
> >> something similar to a critical security update to your OS, say, which
> >> needs to be well vetted by the devs, but doesn't want to wait for the
> >> next point release.
> > 
> > There are several WGs where we've had extended discussions over the text to
> > put in a potential errata report, before the report gets submitted.
> > 
> >> If errata is that mechanism for something controversial, it's news to
> >> me. Mostly what i've seen with errata are minor fixes which the wg chair
> >> and/or authors can sign off easily.
> > 
> > I don't think that errata are the definitive mechanism for potentially
> > controversial things or things that require intrusive changes to resolve,
> > but they can be an appropriate tool.  A drive-by errata report without
> > additional discussion is probably not going to be the most effective way to
> > make progress on such issues, but it can definitely be useful to have the
> > issue documented in an errata report, even as a revision to the RFC is
> > underway to fix the issue.
> > 
> > -Ben
> >