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

Roman Danyliw <rdd@cert.org> Wed, 04 November 2020 17:31 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 1AA353A13AA for <ietf@ietfa.amsl.com>; Wed, 4 Nov 2020 09:31:34 -0800 (PST)
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 iWX5zOGC9_tD for <ietf@ietfa.amsl.com>; Wed, 4 Nov 2020 09:31:32 -0800 (PST)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 134D33A13A5 for <ietf@ietf.org>; Wed, 4 Nov 2020 09:31:31 -0800 (PST)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 0A4HVUWH022135; Wed, 4 Nov 2020 12:31:30 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 0A4HVUWH022135
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1604511090; bh=Q2wgoK4omFoAm+LJg+qiJAQdChWgZR1c7w9fNz/6l7g=; h=From:To:Subject:Date:References:From; b=mpGyFt4FtnvuvbqZI5BTizRysJQiZF0Rw2Aj8SUk8lLAZiVvtpuwMSJQTCyzNORvs yLMqrZxv07Lpfe5xdP8okfxs+DVyyQZeZ00M5yyuA455RPLGw3F9e8kNRopZwwRaHb aNuc7E9wuCTS5PXNzJaCs+vnlj/Pt6YaSqrfEee0=
Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 0A4HVTeR006505; Wed, 4 Nov 2020 12:31:29 -0500
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 4 Nov 2020 12:31:29 -0500
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; Wed, 4 Nov 2020 12:31:29 -0500
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+D5Cfcs8r0xT9Wg091feiESVgCCVpqAAB9GCQABt3DDUA==
Date: Wed, 04 Nov 2020 17:31:27 +0000
Message-ID: <e000ecefa83143ac8819c307bd86d243@cert.org>
References: <5081794697df44d8bd76b675cf08dc23@cert.org> <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/MGNlTzEJeDV9RV9elQxJGSZVelk>
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: Wed, 04 Nov 2020 17:31:34 -0000

Hi Dan!

> -----Original Message-----
> From: Roman Danyliw
> Sent: Monday, October 26, 2020 7:51 PM
> To: 'Dan Harkins' <dharkins@lounge.org>; ietf@ietf.org
> Subject: RE: Call for Community Feedback: Guidance on Reporting Protocol
> Vulnerabilities
> 
> 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).

Please see the revised text to address a workflow for individual submission:

https://github.com/ietf/vul-reporting-guidance/commit/9698c728b900307f74a2649720755b35c6b0523b

Let me know if this doesn't address your feedback.

Thanks,
Roman

> 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_Vulnerabi
> > > li
> > > 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/vulner
> > > ab
> > > 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