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

Eliot Lear <lear@cisco.com> Wed, 28 October 2020 16:20 UTC

Return-Path: <lear@cisco.com>
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 D54F43A011B for <ietf@ietfa.amsl.com>; Wed, 28 Oct 2020 09:20:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 PAdqPXsoTYfL for <ietf@ietfa.amsl.com>; Wed, 28 Oct 2020 09:20:57 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C5E3A010A for <ietf@ietf.org>; Wed, 28 Oct 2020 09:20:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14584; q=dns/txt; s=iport; t=1603902056; x=1605111656; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Kl/60Ke1rE3np5EdSyAOZa7atPYilKtODASrg+RQn/c=; b=NFp0xoJwYEr7Bp+MOZ1MQ6ecMtIsa/Odq/Jxh0ZPeCn+jUWNkuwCRMc8 q0pKofpmqiE/aQNqo2H6y64TVlolQuENzBDDr0nGlM0/uFxzOf1PTPqiD fz+Q43MyCRPKbYIoKyyREBV+784RnX3jfabJoTi+pIjVsmBBhAKjZSrKg c=;
X-IPAS-Result: A0AnAAA9mZlf/xbLJq1gHAEBAQEBAQcBARIBAQQEAQGBewcBAQsBgSJSBoF0ASASLYQ9iCVgiA6UC4YdFIFpCwEBAQ0BAS8EAQGESgKCBiY0CQ4CAwEBAQMCAwEBAQEFAQEBAgEGBG2FbYVyAQEBAQIBHQZIAwsFCwsOCicDAgJGEQYTFAGDEYJdIKx8doEyhVeFAIE4AYZjgzWDO4IAgTgcgk0+hAcBARIBV4JhM4IsBKZzkRqCdYMYjE2LGwMfgxeKDoUgKY5ysB2DXwIEBgUCFYFUOmdwMxoIGxU7KgGCPj4SGQ2OKxeBAgEJjRtAAzA4AgYBCQEBAwmOSAEB
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.77,427,1596499200"; d="scan'208,217"; a="28266311"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Oct 2020 16:20:52 +0000
Received: from [10.61.234.166] ([10.61.234.166]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 09SGKpU3023706 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Oct 2020 16:20:51 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <4FA7CEDE-0C67-43C5-922C-9B7C277E2487@cisco.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_549C1C7A-B700-4000-9F87-D8FE84D24E13"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Date: Wed, 28 Oct 2020 17:20:51 +0100
In-Reply-To: <608e7b38-57a6-df5f-d0ea-9ddb666a6e3f@mtcc.com>
Cc: The IETF List <ietf@ietf.org>
To: Michael Thomas <mike@mtcc.com>
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> <608e7b38-57a6-df5f-d0ea-9ddb666a6e3f@mtcc.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-Outbound-SMTP-Client: 10.61.234.166, [10.61.234.166]
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/NXtmdcOj0bdEF2Of5HFtlvt4S2g>
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, 28 Oct 2020 16:20:59 -0000

Hi Michael,

> On 28 Oct 2020, at 16:24, Michael Thomas <mike@mtcc.com> wrote:
> 
> 
> 
> On 10/28/20 3:33 AM, Eliot Lear wrote:
>> 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.
>> 
>> 
> This makes an assumption that the authors will be receptive to the vulnerability. My two experiences was that they were not.
> 

Let’s accept that this does indeed happen for two reasons:

The report is not a protocol vulnerability, but an implementation vulnerability or a misunderstanding.
The report is a protocol vulnerability and the WG has some cultural issue that needs to be overcome.

On the first point, discussion will sort it quickly, I hope.  On the second point, it’s just something to work on, and work on it we as a community should.  Security researchers are indeed here to help, and we just have to reinforce that at every turn.  It is sometimes hard to draw the distinction between an implementation bug and a protocol bug, particularly if the protocol is in some way underspecified.  But to this point:
> That hopefully is not universal, but not considering the tendency toward the "i know this, who are you?" reaction is to my mind one of the key problems here. The other problem is that somebody off the street is not going to know arcane IETF process mechanisms which can be wielded as another cudgel to make that reporter go away. That just got used on me yesterday and is perfectly timely: why didn't i follow process XYZ? because i don't know anything about process XYZ, and by the time I understand process XYZ i've already lost interest because i didn't sign up for a protracted bureaucratic fight. that and i have no stake in the outcome beyond just being interested or a user; if you make me have to fight for it, you've lost me.
> 

Yes.  And what I am getting at is a little bit of hand holding on our side for, as I said, people who don’t want to play “Inside Baseball” could be very useful to this community.

> The thing about security flaws in particular is they can be very subtle and hard to explain. It took me several readings of the DNS Race flaw to get the jist of it years ago, and that was written up by Vixie after the fact to explain it. The front line is going to be considerably messier since the reporter is not likely an expert in every aspect of the protocol and may get some things right and some things wrong. The wrong things can then be used to dismiss the problem wholesale, especially with the authors who have built in bias.
> 

And that’s something cultural to work on.

> Don't a lot of working groups have security area liasons these days? People who don't have a stake in the outcome, per se? Maybe that's where you want to route this.
> 

So long as the liaisons aren’t the only ones who are routed to, having someone who can facilitate a conversation is of course only goodness, but they cannot gate.

Eliot