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 62BDE3A00D2 for <ietf@ietfa.amsl.com>; Tue, 27 Oct 2020 04:56:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, 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 vYvreiOTNbq0 for <ietf@ietfa.amsl.com>; Tue, 27 Oct 2020 04:56:45 -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 116F23A00DB for <ietf@ietf.org>; Tue, 27 Oct 2020 04:56:44 -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 09RBugYd047080; Tue, 27 Oct 2020 07:56:42 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 09RBugYd047080
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1603799802; bh=CmNHjJwkGo1iCMm+QxmznNkHxVPm3njA68IQQ5kKk18=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=g/YHn/ZM3lMk/8SanDdS4N7aM2GEgSGprTH1SDNpnhOnb4fXuOpNAiUXToNdhamAX CLsq3F54zgkL258Tyehg/jWTAK2u0lIyPLOwBG7U2p280wyGh7OJbG+ScOr+rHgxic ayLAOEiGgU3m6z1J5wvcEpqnGbNQOFPzqb6KTY7k=
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 09RBud9b024984; Tue, 27 Oct 2020 07:56:39 -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:39 -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:39 -0400
From: Roman Danyliw <rdd@cert.org>
To: Eliot Lear <lear@cisco.com>
CC: The IETF List <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+D5Cfcs8r0xT9Wg091feiESVgCMHiYAABWiuxA=
Date: Tue, 27 Oct 2020 11:56:36 +0000
Message-ID: <362d68dd6117452f925322f8180de423@cert.org>
References: <5081794697df44d8bd76b675cf08dc23@cert.org> <09B0A1A1-6534-4A44-A162-9962FFF8D8B8@cisco.com>
In-Reply-To: <09B0A1A1-6534-4A44-A162-9962FFF8D8B8@cisco.com>
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: multipart/alternative; boundary="_000_362d68dd6117452f925322f8180de423certorg_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/rjmVkI9IzU6UhsrNzWKRmy88xOY>
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:47 -0000

Hi Eliot!

Thanks for the review.  Inline …

From: Eliot Lear <lear@cisco.com>
Sent: Monday, October 26, 2020 5:32 AM
To: Roman Danyliw <rdd@cert.org>
Cc: The IETF List <ietf@ietf.org>
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities

Hi Roman,

Thank you for writing this down.  It’s a great initiative.  I would suggest some revision to accomplish two key points in support of the goal encouraging researchers to report problems to us:


  *   Simplify the flow
  *   Make clear their work is appreciated

Starting with the latter, the following statement in the document should be close to the first words read:

“The IETF values your critical analysis of its work.”

That sets the tone for the rest of the document.  You might modify it to capture Rich’s point, “While we are unable to pay bug bounties, The IETF values your critical analysis of its work.”

[Roman]  Point taken.  The opening can be even stronger about encouraging input.

To make it clear who “your’’ is, you might want to simply state at the beginning of the document, “Dear security researchers”.  That way you can entirely nuke out scope, which most people will just find to be officiousness getting in the way of what they’re really trying to learn, which is how to disclose to the IETF.

Second, it helps to simplify by having a routing function.  Researchers and most others don't want to play Inside Baseball with us.  Since you are already advertising “protocol-vulnerability@ietf.org<mailto:protocol-vulnerability@ietf.org>” why not just let that be the lead point of contact, and say something like this:

If you believe you’ve discovered a protocol vulnerability, we would appreciate it if you were to email “protocol-vulnerability@ietf.org<mailto:protocol-vulnerability@ietf.org>” as well as the document authors.  You are also invited to take your findings to any open IETF working group or mailing list that you believe would be appropriate.  All of our work is public, and therefore, disclosing to a working group or mailing list is public.  In some cases, we may ask you to file an errata, and we will guide you through that process.

The idea here is that fewer words are better, and less process put in front of people that will cause them a bad taste is better.  I’m not suggesting those be the only words - talking about how to disclose privately is worth while (IMHO); also setting expectations is important.  Old cruft or non-IETF docs may never get fixed, and even newer stuff might take quite a while.  And encouraging participation in the fix is of course appreciated.  New stuff in drafts might be fixed very quickly!  But I don’t see that it is necessary or helpful to go into too much detail about the structure of our work.  The KISS principle applies.  Thus the diagram should be unnecessary.  If a diagram is necessary, it means KISS has been violated.

[Roman] I like you words.  They are more consistent with common industry practice that attempts to simplifying the onus of the reporting process and an understood workflow around it.  The new LLC vulnerability disclosure policy (https://www.ietf.org/about/administration/policies-procedures/vulnerability-disclosure) takes this same approach.

[Roman] The text proposed for the vulnerability reporting web page is longer (and more complex and certainly not KISS), but significantly less ambitious than yours in scope.  It appear that your concise text would redefine the IETF culture and process about handling a certain class of information.  That’s a big step that would require a comprehensive discussion and deliberate consensus process around it.  What’s being proposed instead is an initial outreach step with a “Tao of the IETF”-style prose which explains the as-is process to an IETF newcomer on reporting vulnerability information – almost no new process/culture invented (there will be a new email alias which will act as a final catch all).

Finally, while we might not give bug bounties, we could at least toss these people a tee shirt or a mug, or if nothing else, honorable mention at meetings or in proceedings.  Again, it reinforces that we think their contributions are important.

[Roman] Completely agree.  These are nice gestures that should be considered.  Additionally, I’ve seen partnerships between the IETF and professional societies to create venues to showcase cutting edge security analysis on IETF work but also be peer-reviewed to contribute to a publication record.  That said, the proposal is web-page text to describe how the IETF works, not new process.

Regards,
Roman




Best regards,

Eliot




On 23 Oct 2020, at 20:46, Roman Danyliw <rdd@cert.org<mailto:rdd@cert.org>> 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_Vulnerabilities_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<mailto: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<http://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/vulnerability-disclosure