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

Dan Harkins <> Mon, 26 October 2020 04:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D4983A18DA for <>; Sun, 25 Oct 2020 21:51:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.146
X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0r-Ss5MtOtzW for <>; Sun, 25 Oct 2020 21:51:48 -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 7E1333A18D9 for <>; Sun, 25 Oct 2020 21:51:47 -0700 (PDT)
Received: from ( []) by (PMDF V6.8 #2433) with ESMTP id <> for; Sun, 25 Oct 2020 23:51:47 -0500 (CDT)
Received: from blockhead.local ([]) by (PMDF V6.7-x01 #2433) with ESMTPSA id <> for; Sun, 25 Oct 2020 21:47:31 -0700 (PDT)
Received: from ([] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by ([]) (PreciseMail V3.3); Sun, 25 Oct 2020 21:47:31 -0700
Date: Sun, 25 Oct 2020 21:51:45 -0700
From: Dan Harkins <>
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
In-reply-to: <>
Message-id: <>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8; format=flowed
Content-language: en-US
Content-transfer-encoding: 8BIT
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
X-PMAS-SPF: SPF check skipped for authenticated session (, send-ip=
X-PMAS-External-Auth: [] (EHLO blockhead.local)
References: <>
X-PMAS-Software: PreciseMail V3.3 [201022b] (
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
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: Mon, 26 Oct 2020 04:51:50 -0000


   Not all RFCs are the product of a working group so I think the 
section dealing
with "Expectations from the IETF" should address what the IETF feels it 
should do
wrt to RFCs published by the IETF that were not products of a working 
group. The
existing text seems to only address issues with RFCs that were the 
produce of a
(possibly closed) working group. This probably has an influence on 
Figure 1 too--
to be specific, before the decision of "4" there should be a decision on the
question of whether this is about an RFC that the IETF feels it needs to 



On 10/23/20 11:46 AM, Roman Danyliw wrote:
> Hi!
> The Internet Engineering Steering Group (IESG) is seeking community input on reporting protocol vulnerabilities to the IETF.  Specifically, the IESG is proposing guidance to be added to the website at [1] to raise awareness on how the IETF handles this information in the standards process.  The full text (which would be converted to a web page) is at:
> This text is intended to be written in an accessible style to help vulnerability researchers, who may not be familiar with the IETF, navigate existing processes to disclose and remediate these vulnerabilities.  With the exception of creating a last resort reporting email alias (, this text is describing current practices in the IETF, albeit ones that may not be consistently applied.
> This guidance will serve as a complement to the recently written IETF LLC infrastructure and protocol vulnerability disclosure statement [2].
> The IESG appreciates any input from the community on the proposed text and will consider all input received by November 7, 2020.
> Regards,
> Roman
> (for the IESG)
> [1] This guidance text would be added to a new URL at, and then referenced from,,, and
> [2]

"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius