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

Eliot Lear <> Mon, 26 October 2020 09:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE9A13A1A02 for <>; Mon, 26 Oct 2020 02:31:55 -0700 (PDT)
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 h7Ye7r3k1WMH for <>; Mon, 26 Oct 2020 02:31:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 834063A1A11 for <>; Mon, 26 Oct 2020 02:31:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=12779; q=dns/txt; s=iport; t=1603704713; x=1604914313; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=5HUkuO0u3u7A7HD/dWp80UyDG+tNAZMKo9ZULh0Baik=; b=Hb4dbZrC/CX/PyO22fBek1LNyqbZSZhQTyUSO0KCQfIXfFeOgKolLVR4 kjm+yc0TT6D8s4ZG5vVMZtOIM7XXuse2vDAgmnAami3kYrndUdBysD4hV 7ZyToHibmV4JVwN1mw5P/JLmq8bVrfs5Vi727V7BXxZ+uvE0oga2hVi6C 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BsAAAYl5Zf/xbLJq1gGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBgg+BI1gvSSdRBAEyJAiEPIkFh2cmlAuGMYF?= =?us-ascii?q?pCwEBAQ0BASUKBAEBhEoCggwmOBMCAwEBCwEBBQEBAQIBBgRthWEMhXIBAQE?= =?us-ascii?q?CAQEdBiYlCwULCQIOCicDAgJGEQYTCQuDEgGCXCAIB5JAmw92gTKEUkFEhHO?= =?us-ascii?q?BOIZkgzWDO4IAgREnDBCBT34+glELAQEBgSQFARIBgzgzgiwEkDanUIJ0gxa?= =?us-ascii?q?XYwMfgxePVo5xpD+LV4NfAgQGBQIVgWsjZ3AzGggbFTsqAYI+CTUSGQ2PRAE?= =?us-ascii?q?Jh1aFQ0ADMAIFBisCBgEJAQEDCY1pXwEB?=
X-IronPort-AV: E=Sophos; i="5.77,417,1596499200"; d="scan'208,217"; a="30634739"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Oct 2020 09:31:49 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id 09Q9VkK8012846 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Oct 2020 09:31:48 GMT
From: Eliot Lear <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E490AD78-7E2B-416E-B93D-2685B9F61BE3"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
Date: Mon, 26 Oct 2020 10:31:46 +0100
In-Reply-To: <>
Cc: The IETF List <>
To: Roman Danyliw <>
References: <>
X-Mailer: Apple Mail (2.3608.
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: Mon, 26 Oct 2020 09:31:56 -0000

Hi Roman,

Thank you for writing this down.  It’s a great initiative.  I would suggest some revision to accomplish two key points in support of the goal encouraging researchers to report problems to us:

Simplify the flow
Make clear their work is appreciated

Starting with the latter, the following statement in the document should be close to the first words read:

“The IETF values your critical analysis of its work.”

That sets the tone for the rest of the document.  You might modify it to capture Rich’s point, “While we are unable to pay bug bounties, The IETF values your critical analysis of its work.”

To make it clear who “your’’ is, you might want to simply state at the beginning of the document, “Dear security researchers”.  That way you can entirely nuke out scope, which most people will just find to be officiousness getting in the way of what they’re really trying to learn, which is how to disclose to the IETF.

Second, it helps to simplify by having a routing function.  Researchers and most others don't want to play Inside Baseball with us.  Since you are already advertising “ <>” why not just let that be the lead point of contact, and say something like this:

If you believe you’ve discovered a protocol vulnerability, we would appreciate it if you were to email “ <>” as well as the document authors.  You are also invited to take your findings to any open IETF working group or mailing list that you believe would be appropriate.  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 errata, and we will guide you through that process.

The idea here is that fewer words are better, and less process put in front of people that will cause them a bad taste is better.  I’m not suggesting those be the only words - talking about how to disclose privately is worth while (IMHO); also setting expectations is important.  Old cruft or non-IETF docs may never get fixed, and even newer stuff might take quite a while.  And encouraging participation in the fix is of course appreciated.  New stuff in drafts might be fixed very quickly!  But I don’t see that it is necessary or helpful to go into too much detail about the structure of our work.  The KISS principle applies.  Thus the diagram should be unnecessary.  If a diagram is necessary, it means KISS has been violated.

Finally, while we might not give bug bounties, we could at least toss these people a tee shirt or a mug, or if nothing else, honorable mention at meetings or in proceedings.  Again, it reinforces that we think their contributions are important.

Best regards,


> On 23 Oct 2020, at 20:46, Roman Danyliw <> wrote:
> Hi!
> The Internet Engineering Steering Group (IESG) is seeking community input on reporting protocol vulnerabilities to the IETF.  Specifically, the IESG is proposing guidance to be added to the website at [1] to raise awareness on how the IETF handles this information in the standards process.  The full text (which would be converted to a web page) is at:
> This text is intended to be written in an accessible style to help vulnerability researchers, who may not be familiar with the IETF, navigate existing processes to disclose and remediate these vulnerabilities.  With the exception of creating a last resort reporting email alias (, this text is describing current practices in the IETF, albeit ones that may not be consistently applied.
> This guidance will serve as a complement to the recently written IETF LLC infrastructure and protocol vulnerability disclosure statement [2]. 
> The IESG appreciates any input from the community on the proposed text and will consider all input received by November 7, 2020.
> Regards,
> Roman
> (for the IESG)
> [1] This guidance text would be added to a new URL at, and then referenced from,,, and
> [2]