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

Benjamin Kaduk <kaduk@mit.edu> Wed, 28 October 2020 18:31 UTC

Return-Path: <kaduk@mit.edu>
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 A6D3E3A09C0 for <ietf@ietfa.amsl.com>; Wed, 28 Oct 2020 11:31:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 UV8zcd30EfSm for <ietf@ietfa.amsl.com>; Wed, 28 Oct 2020 11:31:42 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 390653A09C1 for <ietf@ietf.org>; Wed, 28 Oct 2020 11:31:41 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09SIVUtf026357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Oct 2020 14:31:35 -0400
Date: Wed, 28 Oct 2020 11:31:29 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Michael Thomas <mike@mtcc.com>
Cc: Roman Danyliw <rdd@cert.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Message-ID: <20201028183129.GD39170@kduck.mit.edu>
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> <7f55408ce3e84c93b22f69765deed892@cert.org> <fe695697-74ef-d707-2883-e83052483356@mtcc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <fe695697-74ef-d707-2883-e83052483356@mtcc.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/mFSKXl3X_p3B9nuO3qezWBN59fc>
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 18:31:44 -0000

Hi Mike,

On Wed, Oct 28, 2020 at 09:23:31AM -0700, Michael Thomas wrote:
> 
> On 10/28/20 8:51 AM, Roman Danyliw wrote:
[...]
> > [Roman] To my knowledge, formal security area liaisons are not common 
> > practice across WG, unless explicitly requested. I would characterize 
> > such formal arrangements as fairly rare.  More common are requests for 
> > early Security Directorate (SECDIR) reviews and trying to entice those 
> > with security experience to participate in WGs that feel they need 
> > that review.  Likewise, there has been an informal push in recent 
> > years to include language related to security in charters (which may 
> > have helped only a little bit in identifying concerns and need for 
> > help early in a work’s lifecycle).
> >
> 
> I seem to recall seeing security area reviews as the document is winding 
> toward last call, but it's been a long time since I've really 
> participated more than just cursorily. Part of why I chimed in is 
> because i'm part of the outside-looking-in kind of crowd this seems to 
> be addressing. I probably know more than your average security 
> researcher about ietf process, culture etc, but it's not my $DAYJOB by 
> any means and i'm pretty clueless about process archana.
> 
> The other part of this is that in my two experiences, it wasn't THIS IS 
> WRONG YOU MUST FIX!!! It was "is there a problem here? can somebody 
> explain to me why it isn't?" I expect that most credible submissions are 
> going to be more like the latter than the former, but even those were 
> met with either hostility or indifference. Assuming it's been filtered 
> to being a credible concern, it seems to me that it ought to be 
> independently validated (or not), and better with somebody who doesn't 
> have a stake in the rfc (authors, participants) who aren't eager to open 
> pandora's box. At the point somebody with known clue can vouch that 
> there's a good probability there's some there there, it become much 
> harder for the working group and authors to ignore.

I believe that the WG chairs/ADs can and should play this role of helping
to determine whether there is a real concern.

-Ben