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

["Joel M. Halpern" <[e-mail]>]

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