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

Benjamin Kaduk <> Wed, 28 October 2020 18:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 00A493A0AA3 for <>; Wed, 28 Oct 2020 11:42:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1NEjRKTplfLw for <>; Wed, 28 Oct 2020 11:42:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AEED03A0A9E for <>; Wed, 28 Oct 2020 11:42:15 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 09SIg83Q030221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Oct 2020 14:42:13 -0400
Date: Wed, 28 Oct 2020 11:42:08 -0700
From: Benjamin Kaduk <>
To: Michael Thomas <>
Cc: The IETF List <>
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Oct 2020 18:42:17 -0000

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.