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

Roman Danyliw <rdd@cert.org> Tue, 27 October 2020 11:56 UTC

Return-Path: <rdd@cert.org>
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 C63C63A00E0 for <ietf@ietfa.amsl.com>; Tue, 27 Oct 2020 04:56:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 vL_Cvh4-tXVi for <ietf@ietfa.amsl.com>; Tue, 27 Oct 2020 04:56:44 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 309B03A00D2 for <ietf@ietf.org>; Tue, 27 Oct 2020 04:56:43 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 09RBugYL047081; Tue, 27 Oct 2020 07:56:42 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 09RBugYL047081
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1603799802; bh=1Dy8JQ8TsqVAP3RGMQ+2C/dT54P2isU2yVJAJJv/ypI=; h=From:To:Subject:Date:References:In-Reply-To:From; b=L/1e2nlaYcsnZdDJ8/vwRoykeqQmMiM32TMQ+cwmhVh0nv9A0pX58MBsdVmSCLZxK 9B6c/QJZh/UNgpU3jQ+gRb3wxUc9CYByxwWyNL5ouujef/u2xT77IYYP7Leq0fBDAX vaqjfuQuXxhrsI7rfGOlclSmsIU9f/qDNOBEA6z0=
Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 09RBucZa024973; Tue, 27 Oct 2020 07:56:38 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 27 Oct 2020 07:56:38 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Tue, 27 Oct 2020 07:56:38 -0400
From: Roman Danyliw <rdd@cert.org>
To: Dan Harkins <dharkins@lounge.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: RE: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Thread-Topic: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Thread-Index: Adapa+D5Cfcs8r0xT9Wg091feiESVgCCVpqAAB9GCQA=
Date: Tue, 27 Oct 2020 11:56:35 +0000
Message-ID: <e6871145ef094924a7f263e2658bd696@cert.org>
References: <5081794697df44d8bd76b675cf08dc23@cert.org> <3965ff3d-af5a-addb-1c31-8c356c296329@lounge.org>
In-Reply-To: <3965ff3d-af5a-addb-1c31-8c356c296329@lounge.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.202.126]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/FEHwYlgEfQ_6q2JZGkrubLxhitI>
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: Tue, 27 Oct 2020 11:56:46 -0000

Hi Dan!

Thank you for the feedback!

> -----Original Message-----
> From: ietf <ietf-bounces@ietf.org> On Behalf Of Dan Harkins
> Sent: Monday, October 26, 2020 12:52 AM
> To: ietf@ietf.org
> Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol
> Vulnerabilities
>
>
>    Howdy,
>
>    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 address.

Good point.  Let me figure out how to best finesse the existence of AD sponsored documents, without adding too much (more) complexity.

Regardless of the editorial approach, let me know if the possible end states aren't "errata" (8) or "using the general alias" (10), perhaps with a trip through "is there an active working group on the topic" (3).

Regards,
Roman

>    regards,
>
>    Dan.
>
> 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:
> >
> > https://www.ietf.org/media/documents/Guidance_on_Reporting_Vulnerabili
> > ties_to_the_IETF_sqEX1Ly.pdf
> >
> > 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 (protocol-vulnerability@ietf.org), 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
> > https://www.ietf.org/standards/rfcs/vulnerabilities, and then
> > referenced from www.ietf.org/contact,
> > https://www.ietf.org/standards/process/,
> > https://www.ietf.org/standards/rfcs/, and
> > https://www.ietf.org/topics/security/
> >
> > [2]
> > https://www.ietf.org/about/administration/policies-procedures/vulnerab
> > ility-disclosure
> >
> >
>
> --
> "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