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

Toerless Eckert <> Wed, 28 October 2020 17:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A24A3A03EE for <>; Wed, 28 Oct 2020 10:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J5KtNscUIm7n for <>; Wed, 28 Oct 2020 10:39:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB2B63A010A for <>; Wed, 28 Oct 2020 10:39:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9F4AE548659; Wed, 28 Oct 2020 18:39:13 +0100 (CET)
Received: by (Postfix, from userid 10463) id 97E52440059; Wed, 28 Oct 2020 18:39:13 +0100 (CET)
Date: Wed, 28 Oct 2020 18:39:13 +0100
From: Toerless Eckert <>
To: Eliot Lear <>
Cc: Pete Resnick <>, Ned Freed <>, The IETF List <>
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
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 17:39:20 -0000

Eliot, *:

I am not even parsing all the things you wrote below, i am sure they are right.

To me they are be another proof point that at this stage IETF has
accumulated enough processes, twist and complications that one of the top
things to think about even bringing outsiders more into the IETF not only
effectively reporting but maybe helping to take steps towards resolving security issues
is to have some form of "shepherding" through he process. 

To that extend, it would be good if even the "reporting" mail alias would
not be imited to a secret small group of participants but a broader set
of IETF participants, especially those who would volunteer to help
spehpherding the process.

Even the writeup is longer than i have seen on any other incident report web page
of other organizations.


On Wed, Oct 28, 2020 at 06:00:48PM +0100, Eliot Lear wrote:
> Pete,
> > On 28 Oct 2020, at 17:42, Pete Resnick <> wrote:
> > 
> > The fact that you think invoking them makes you a "drama queen" means that you are part of the problem. And the idea that if you "don't have a dog in the fight" means that you shouldn't fully participate (including using the pushback mechanisms we have), you're not understanding what the IETF is supposed to be about: We have plenary meetings and Last Calls and the like so that groups can get cross-area and outside feedback. Failure to call out problems simply because you're not a primary player is exacerbating the cultural problem you claim to see.
> This is where I think there may be some subtle issue, and I don???t want to make this all about Mike.  Many researchers have no equities in our organization.  They may not even have a fix available for the very problem that they have found.  We have red teams for a reason: it???s just a different muscle.  So they see their job as finished when they???ve reported.  And then they???re on to the next thing.  That???s their incentive model.  Mike just happens to care more than most, but we shouldn???t optimize around him.
> Eliot