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

Eliot Lear <> Fri, 06 November 2020 10:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C65B3A1274 for <>; Fri, 6 Nov 2020 02:52:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.6
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rv37bTgzC5L9 for <>; Fri, 6 Nov 2020 02:52:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0233F3A11EC for <>; Fri, 6 Nov 2020 02:51:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=23733; q=dns/txt; s=iport; t=1604659898; x=1605869498; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=uHrxi9yszJMRuNcCAYhUuFquxyScH83bFx4elt2qhbE=; b=Elo130zb+3D5NSamrNBLhAuAxrAMWtLoo4ewebpZlw6hqPBHvWchlzq2 bmeaRbA+Ul4ZRuGlaP9UvXzTnHqjwAcFA8MxvZAKQEzdeWUNumFclKoTe aUAeSzdZFoCUBfnHDQ91U6ea1fK+7FfRwhSaKENuKAdVLYSAyLRW3wdTl o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.77,456,1596499200"; d="scan'208,217"; a="30917826"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Nov 2020 10:51:33 +0000
Received: from [] ([]) by (8.15.2/8.15.2) with ESMTPS id 0A6ApWOu023818 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Nov 2020 10:51:33 GMT
From: Eliot Lear <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4D187927-B7D1-4400-954F-29A31A237903"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Date: Fri, 6 Nov 2020 11:51:32 +0100
In-Reply-To: <>
Cc: The IETF List <>
To: Roman Danyliw <>
References: <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3608.
X-Outbound-SMTP-Client:, []
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: Fri, 06 Nov 2020 10:52:10 -0000

Thanks, Roman.  I appreciate the work.  Please take all of these as suggestions for your consideration, and nothing more (e.g., I’m not pounding my shoe on the table).

My thinking is this:

> Detailed guidance to navigate the disclosure of and remediate of vulnerabilities in the IETF is documented below.

… combined with The Fully Monty below might still leave security researchers with the feel that the onus is on them to drive a process that they may see as daunting.  It is only their responsibility if they wish to take it on.  They may find that it’s easier to talk to a C-Net reporter instead, and then have someone else pick up the work and go through our process if they wish, or not.

The solution for this is probably simple enough: a slight tonal change and a click.  That is:

> Click <here> if you would like to see the full explanation of the process for disclosure and remediation of vulnerabilities.

That gives them a choice in terms of how far down the rabbit hole they want to go with us, but makes clear that there is at least a reporting path if they want to start slowly.

A few other comments:

The scope paragraphs are overly complex.  They can be reduced to the following:

> You can use this disclosure policy to report vulnerabilities in our protocols and technical specifications that you find in either RFCs or our working documents, Internet-Drafts (I-Ds).  You should report specific implementation vulnerabilities to their maintainers, and not to us.  If you spot a vulnerability on our web site or tools, click <here> to report it, and it will be reviewed by the appropriate tooling team.

If you feel more comfortable putting this in passive, that’s a stylistic thing.  I’m an informal guy.

The section title, “Expectations from the IETF” doesn’t quite seem right.  “From” doesn’t usually follow “Expectations”, and the writing below doesn’t make a correction obvious.  I won’t claim to be the world’s best grammarian, but perhaps that’s worth a quick review.

Thanks again for getting this done.


> On 6 Nov 2020, at 03:45, Roman Danyliw <> wrote:
> Hi Eliot!
> Merging additional feedback on the executive summary and going for even more simplicity on the process so that the catch-all alias can be mentioned quickly, see the following:
> <>
> Roman
> From: Roman Danyliw 
> Sent: Wednesday, October 28, 2020 10:53 AM
> To: 'Eliot Lear' < <>>
> Cc: The IETF List < <>>
> Subject: RE: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
> Hi Eliot!
> From: Eliot Lear < <>> 
> Sent: Wednesday, October 28, 2020 6:34 AM
> To: Roman Danyliw < <>>
> Cc: The IETF List < <>>
> Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
> Hi Roman,
> On 27 Oct 2020, at 20:06, Roman Danyliw < <>> 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 “ <>” 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.
> Again, fewer words are better.  And again, adding a few sentences about expectations is just fine.  This should make clear that the mailing list is intended to provide assistance, not triage, and it is entirely optional.
> Does that make it clearer that we’re not gate keeping?
> [Roman] Indeed it does.  I’d recommend a bit more wordsmithing based on the other feedback provided on payment and inclusion, but the substance is there for me.  Let me get the text into github so edits are easier to manage.
> [Roman] To check that we’re on the same page, I see a future version of text like this as the up-front summary.  I believe we still need the existing detailed text to describe the detail process by which to engage the IETF (alluded to in this style of summary).  Agreed?
> Regards,
> Roman
> Eliot
> Eliot