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

Benjamin Kaduk <> Wed, 28 October 2020 18:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6D3E3A09C0 for <>; Wed, 28 Oct 2020 11:31:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UV8zcd30EfSm for <>; Wed, 28 Oct 2020 11:31:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 390653A09C1 for <>; Wed, 28 Oct 2020 11:31:41 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (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 <>
To: Michael Thomas <>
Cc: Roman Danyliw <>, "" <>
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.