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

"Joel M. Halpern" <> Wed, 28 October 2020 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D6D263A0B3A for <>; Wed, 28 Oct 2020 11:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.345
X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m64AMYYzC0jt for <>; Wed, 28 Oct 2020 11:53:57 -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 9C0463A0B38 for <>; Wed, 28 Oct 2020 11:53:57 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CLyQs36zvz6G9Xj; Wed, 28 Oct 2020 11:53:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1603911237; bh=L+kkV5vQ+tPi6Qs3uvISLxJsIoJq64ZOxQ7Ld79sgeY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=V0oJbmw78mkm2BIfm4cLzOwhVIJ/I/d72GMQODYFe0VzkwFndBSY7c09gjXc3Rq9l EqBOKLhB+7S+RZcEw0QiILW2PVlfMuEwGvsLjM8efYsGHuVtiohrMqhBPSCPqEM8+7 ATGTKbBWYh3CjWmBgn5KKtU3lBhJsefg0TXPsOgo=
X-Quarantine-ID: <mFJZmAqGU7LZ>
X-Virus-Scanned: Debian amavisd-new at
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4CLyQr5C7Zz6G7s9; Wed, 28 Oct 2020 11:53:56 -0700 (PDT)
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
To: Benjamin Kaduk <>, Michael Thomas <>
Cc: The IETF List <>
References: <> <> <> <> <> <> <> <> <> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Wed, 28 Oct 2020 14:53:56 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
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:53:59 -0000

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

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 

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 


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