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

Michael Thomas <> Tue, 27 October 2020 15:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D31D83A0D84 for <>; Tue, 27 Oct 2020 08:17:34 -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 uZIEMiNe0F7R for <>; Tue, 27 Oct 2020 08:17:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5792B3A0D7A for <>; Tue, 27 Oct 2020 08:17:33 -0700 (PDT)
Received: by with SMTP id m3so903633pjf.4 for <>; Tue, 27 Oct 2020 08:17:33 -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=AuwVxSsJO9mo6FrY4qH83VAhw9kpJSIM79S4Xg3Nt98=; b=E8tM3H6LTIkjSFlbwFnO428VGlRa1NNUZaUnsTv8YvsGnNsSJCpxhXXWEcCANlwHGo CQRMp4VZo9hXZCLhJlT2LuXu7aev6lCXfJRQ5PVlFZEN8jP5Btyqd3r88uKKNIG1rzSa 5ZwV0zcVNZL4+HBVHtZ295MJtoKjvPJ/y6aakZFoInX3Ed3qvS7aPEDYnLCYAbFuG8l+ oSgu7tb0IQWi6Dde76dnqGRaIAIawwUDw7E/+9L0XiageUGtlSadDt2P3fzlR5rCinY1 S/5C4gwWSROojYmTRUJu53xC9YTsdVpPC5E73W+lcIdW8B86NbsG56uo76AFNf4pieYI eC9Q==
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=AuwVxSsJO9mo6FrY4qH83VAhw9kpJSIM79S4Xg3Nt98=; b=i+smgwg4+cE00elnwkiRG9W9dJHRXotIhst9zAehNbuo9Kg+/hD1FhUjkCE90+RP+6 EwuidDqvDBZzOhneokJu1hC8iUCfKRs29Ul/fCMGuQx3gpvNm8B9fK2VBP0OOPl1hU1x BSkaHBbPDYRRxJohodW3OTQ4XoE7x8hKQ58pRF8ocoA3Xi/6S6V1JHT9ACvxQe5hGq3x KJg/oq0eJKsqzbyAUHMW/oaUffnYoXGk4unEkyvKzF5Zw3afl57XDz7Lz1pxRsl34jRR 4x7lwIRiIEAdP46r8YCoB1iGOKZYhARclk79xHbRW1iu5y0wL972l/U39bHecZC5PHl4 iC6Q==
X-Gm-Message-State: AOAM532djYX6976cwB6zjj6xUtgHgX8/9Q3Pw6vrkwcgw3Tyw4ncDNdB XUmQKKXPBiFA9pvgyxXjSZvVxumRf6wgBA==
X-Google-Smtp-Source: ABdhPJz/vSkOlF7K+fCkpPcO4UpbFW4XDwpe7NKHUqY0cYYjdal6xqYxdvLHYVDdti8eipYcGdYzIQ==
X-Received: by 2002:a17:90a:df0d:: with SMTP id gp13mr2518648pjb.92.1603811852150; Tue, 27 Oct 2020 08:17:32 -0700 (PDT)
Received: from mike-mac.lan ( []) by with ESMTPSA id o65sm2709630pga.42.2020. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2020 08:17:31 -0700 (PDT)
Subject: Re: Call for Community Feedback: Guidance on Reporting Protocol Vulnerabilities
References: <> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Tue, 27 Oct 2020 08:17:29 -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="------------70A229C4205490A5DCD56F18"
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: Tue, 27 Oct 2020 15:17:35 -0000

On 10/27/20 5:20 AM, Eliot Lear wrote:
> 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.
So coming in here a bit late, but isn't the basic problem is that 
working groups don't want to hear criticism or take it seriously? So if 
you figure out problems with the protocol it's pushing on string at best 
and snarl inducing at worst. It would be great if working groups were 
receptive to issues, but there is every incentive to ignore or ridicule 
problems. And then of course there is the problem that there may not be 
a working group anymore.

Mike, who has experienced this repeatedly