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

Michael Thomas <> Wed, 28 October 2020 15:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC8FC3A0A94 for <>; Wed, 28 Oct 2020 08:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JHFA1SpVtrc7 for <>; Wed, 28 Oct 2020 08:24:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E07FE3A0A92 for <>; Wed, 28 Oct 2020 08:24:36 -0700 (PDT)
Received: by with SMTP id y14so3095817pfp.13 for <>; Wed, 28 Oct 2020 08:24:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=3HrqvcAqG4JAGGSX11jneLFzakSo2q+AaGv3RpjJ8a8=; b=oz8wspFQZ8md4yRBhUoIYkvm/vn7CiApq4lLYcNdElD48mQRC7Nz2mtQC5tLIedwfr pdG1AnCYxbny0La0rebvtuzioFjPv+Q38jlMrgnzDAXRAICKbkVa0MNMpRefRGre/hox pd+fFMOHLcnLIqzhSsnFNiCESvTQhnkjt5qd/OMudJllDVKhBTGPMGvPpHGtpo9hz6UD s/ufy4o9QyCqzyg+I/15B3VlKCN2NLhnyomKDVtusfsqq7wy35l8p1BGRxyuPZ1i9eNC leeEvvudI1GQSEu4fy/pk5ifgtcdvoUMYY8g6uFh788En8ty1Yx1l5fVAtxliwRnPvH6 v1MQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=3HrqvcAqG4JAGGSX11jneLFzakSo2q+AaGv3RpjJ8a8=; b=uC7m4+Hk0F4eZ6hxezdtENxPtYdOePz59kj40vcepm+xdszoj8GEWUtOTBn9SGUoCz YBY7XgJnb/B1rgp8bioWNbYRDLyUEyvIrcVwYwOMisMgX9qNgTSOiCXmEYqQmInJGDfd 657dr4EJfNQdQ0Ov2eloi3Uej7ukCMmQuMnCVNfBULqkjsLbCE9wfZG1bsdcgBwO9YUV f9yDenqgF4vx966/tUSgpbLX7YcGx/94ATBxyAyfrjVu7myNcRxQ1BKL6akuDYqn/XOn vDCASYGy/rp9OQ3lGduZBOxoypbiSAtpCgkVTv+LEudsR/kdSJNs1ZwhH5lh6tkYULV5 ktfw==
X-Gm-Message-State: AOAM53360TOepg1VSSrdKD57qzG/amgx5OyAGjcuACiZVXhsjXDh1ieW FpVAzUNllwvRCqgnTNmR3XHjVb+YnvDzyQ==
X-Google-Smtp-Source: ABdhPJxv3uuTAWf5qxyEGak3EnsQSAbEUWNKsDrM0fuaaHXa8mAIHeIBR+z/c7NzzjDC4pa5wIxVhQ==
X-Received: by 2002:a63:380d:: with SMTP id f13mr7174130pga.105.1603898675607; Wed, 28 Oct 2020 08:24:35 -0700 (PDT)
Received: from mike-mac.lan ( []) by with ESMTPSA id z18sm6237720pfn.158.2020. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2020 08:24:34 -0700 (PDT)
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
References: <> <> <> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Wed, 28 Oct 2020 08:24:32 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------2104CA9D71C3B136E525A71C"
Content-Language: en-US
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 15:24:39 -0000

On 10/28/20 3:33 AM, Eliot Lear wrote:
> 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.
This makes an assumption that the authors will be receptive to the 
vulnerability. My two experiences was that they were not. That hopefully 
is not universal, but not considering the tendency toward the "i know 
this, who are you?" reaction is to my mind one of the key problems here. 
The other problem is that somebody off the street is not going to know 
arcane IETF process mechanisms which can be wielded as another cudgel to 
make that reporter go away. That just got used on me yesterday and is 
perfectly timely: why didn't i follow process XYZ? because i don't know 
anything about process XYZ, and by the time I understand process XYZ 
i've already lost interest because i didn't sign up for a protracted 
bureaucratic fight. that and i have no stake in the outcome beyond just 
being interested or a user; if you make me have to fight for it, you've 
lost me.

The thing about security flaws in particular is they can be very subtle 
and hard to explain. It took me several readings of the DNS Race flaw to 
get the jist of it years ago, and that was written up by Vixie after the 
fact to explain it. The front line is going to be considerably messier 
since the reporter is not likely an expert in every aspect of the 
protocol and may get some things right and some things wrong. The wrong 
things can then be used to dismiss the problem wholesale, especially 
with the authors who have built in bias.

Don't a lot of working groups have security area liasons these days? 
People who don't have a stake in the outcome, per se? Maybe that's where 
you want to route this.