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

Roman Danyliw <> Tue, 27 October 2020 19:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B32063A1504 for <>; Tue, 27 Oct 2020 12:06:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c99Hq6d8ovRJ for <>; Tue, 27 Oct 2020 12:06:56 -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 50AF73A14EE for <>; Tue, 27 Oct 2020 12:06:56 -0700 (PDT)
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id 09RJ6rLO016656; Tue, 27 Oct 2020 15:06:53 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 09RJ6rLO016656
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=yc2bmwvrj62m; t=1603825613; bh=dgKbqvCFMUaRROEOJYKS8KmxppqrhUcX7xZxdqpah+w=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=DfPuatDFKNjt8G9NTNnJJLVeiMKIgTOeQ8R1w+henKUySa8GfSctQZBzKW2AZYQvR TqohLPInEf8yM+XJCGNZIp/tRNrkclcB+psKuOWmabNVSMXroZqwvmMGnwN4LrktZq ZPKBJM/6c4mW/ojvZfDXa0cN4nNtHaT0A+MezuP0=
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id 09RJ6jVo048987; Tue, 27 Oct 2020 15:06:45 -0400
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 27 Oct 2020 15:06:45 -0400
Received: from ([fe80::555b:9498:552e:d1bb]) by ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Tue, 27 Oct 2020 15:06:45 -0400
From: Roman Danyliw <>
To: Eliot Lear <>
CC: The IETF List <>
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+D5Cfcs8r0xT9Wg091feiESVgCMHiYAABWiuxAAIoqtAAABE40A
Date: Tue, 27 Oct 2020 19:06:44 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_28e48db9700d49dd97dc0023761a8906certorg_"
MIME-Version: 1.0
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: Tue, 27 Oct 2020 19:06:58 -0000

Hi Eliot!

From: Eliot Lear <>
Sent: Tuesday, October 27, 2020 8:20 AM
To: Roman Danyliw <>
Cc: The IETF List <>
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities

Hi Roman and thanks for the feedback.  Just on this point…

On 27 Oct 2020, at 12:56, Roman Danyliw <<>> wrote:

[Roman] The text proposed for the vulnerability reporting web page is longer (and more complex and certainly not KISS), but significantly less ambitious than yours in scope.  It appear that your concise text would redefine the IETF culture and process about handling a certain class of information.  That’s a big step that would require a comprehensive discussion and deliberate consensus process around it.  What’s being proposed instead is an initial outreach step with a “Tao of the IETF”-style prose which explains the as-is process to an IETF newcomer on reporting vulnerability information – almost no new process/culture invented (there will be a new email alias which will act as a final catch all).

I certainly didn’t set out to change culture OR process.  How do you think I’ve done that?  Perhaps it sounded as if the mailing list is intended to gate keep?  Certainly not what I had in mind.  Just to route. All the usual processes would still apply to what happens next, and the routing function should not be lossy.

[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”.