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

Roman Danyliw <rdd@cert.org> Fri, 06 November 2020 02:45 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 9EDC73A064A for <ietf@ietfa.amsl.com>; Thu, 5 Nov 2020 18:45:27 -0800 (PST)
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 Xqx8XACmnfKO for <ietf@ietfa.amsl.com>; Thu, 5 Nov 2020 18:45:25 -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 648ED3A047D for <ietf@ietf.org>; Thu, 5 Nov 2020 18:45:25 -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 0A62jNNh029128; Thu, 5 Nov 2020 21:45:23 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 0A62jNNh029128
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1604630723; bh=Hvr8ijA5IEuT/ydsUaIS3tI//HMSiRRdbo3eVy9MXcY=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=QESAHv8GgsIgdY7xVoNSrRMdRvChahsXDjn3FAM/8nEskALQYFXZ/d49FPaF49ZLw 3Sn9hy/w/O7wGkOJr3Hyq51d3t46eL4dKIEvJ65483FmlP1SejgHxZ5jpXLXK63yP2 oq98OBCQAmc63Gcq5faiylb9U0bBtDSEQKkpz27w=
Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 0A62jKNk009614; Thu, 5 Nov 2020 21:45:20 -0500
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; Thu, 5 Nov 2020 21:45:19 -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; Thu, 5 Nov 2020 21:45:19 -0500
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+D5Cfcs8r0xT9Wg091feiESVgCMHiYAABWiuxAAIoqtAAABE40AAC191IAAAGB+8AGravgQ
Date: Fri, 6 Nov 2020 02:45:18 +0000
Message-ID: <db801fd08d8b4a3ab8b227311cf30337@cert.org>
References: <5081794697df44d8bd76b675cf08dc23@cert.org> <09B0A1A1-6534-4A44-A162-9962FFF8D8B8@cisco.com> <362d68dd6117452f925322f8180de423@cert.org> <B864FFAE-3E3E-4CEF-B832-4552C8BAE70B@cisco.com> <28e48db9700d49dd97dc0023761a8906@cert.org> <0E4F9F37-6907-496F-BBCA-112FE6CA75FB@cisco.com> <0112bba51cd441d786287b3fb74c3ab0@cert.org>
In-Reply-To: <0112bba51cd441d786287b3fb74c3ab0@cert.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: multipart/alternative; boundary="_000_db801fd08d8b4a3ab8b227311cf30337certorg_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/m_yjhZwTDTLG2-61Knfsesw3uIo>
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: Fri, 06 Nov 2020 02:45:28 -0000

Hi Eliot!

Merging additional feedback on the executive summary and going for even more simplicity on the process so that the catch-all alias can be mentioned quickly, see the following:

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

Roman

From: Roman Danyliw
Sent: Wednesday, October 28, 2020 10:53 AM
To: 'Eliot Lear' <lear@cisco.com>
Cc: The IETF List <ietf@ietf.org>
Subject: RE: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities

Hi Eliot!

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

Hi Roman,

On 27 Oct 2020, at 20:06, Roman Danyliw <rdd@cert.org<mailto:rdd@cert.org>> wrote:

Hi Eliot!

[Roman] In my view, the proposed text effectively says “this is the IETF process and as a last resort, please use the catch all alias”.  My read of your tighter text is the opposite, “here is a new reporting  alias, consider also getting involved in the IETF processes”.  Put in another way, we are actively steering away from established processes (e.g., using the mailing lists) and preferring the triage alias as the first step.  With the reduced text, we are not longer explaining “all the usual processes”.


Ok, Here’s a slightly tweaked version of that text to address how you read the doc:


If you believe you’ve discovered a protocol vulnerability, we very much welcome your contribution.
You are also invited to take your findings to any open IETF working group or mailing list that you believe would be appropriate, in order to discuss protocol improvements to address any vulnerabilities.  If you do not know which IETF working group or mailing list to use or otherwise need help with our processes, we invite you to email “protocol-vulnerability@ietf.org<mailto:protocol-vulnerability@ietf.org>” as well as the document authors, and we will assist you.  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 erratum, and we will be happy to guide you through that process.


Again, fewer words are better.  And again, adding a few sentences about expectations is just fine.  This should make clear that the mailing list is intended to provide assistance, not triage, and it is entirely optional.

Does that make it clearer that we’re not gate keeping?

[Roman] Indeed it does.  I’d recommend a bit more wordsmithing based on the other feedback provided on payment and inclusion, but the substance is there for me.  Let me get the text into github so edits are easier to manage.

[Roman] To check that we’re on the same page, I see a future version of text like this as the up-front summary.  I believe we still need the existing detailed text to describe the detail process by which to engage the IETF (alluded to in this style of summary).  Agreed?

Regards,
Roman

Eliot

Eliot